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Vorwort 



Verträge für die unterschiedlichsten I I - Projekte haben eines gemeinsam: Sie müs- 
sen die Projekte steuerbar machen und mit ihnen oft verbundene Risiken rechtzeitig 
ausschalten oder zumindest reduzieren. Solche Risiken sind mannigfaltig. Dies wird 
durch den Umstand belegt, dass weniger als ein Drittel aller IT-Projekte den ver- 
sprochenen Leistungsumfang zum geplanten Zeitpunkt, im geplanten Budget und 
mit der spezifizierten Qualität erreicht. Dies führt betriebswirtschaftlich zu nicht 
unerheblichen Schäden, die sich durch geeignete Gestaltung und Durchführungs- 
kontrolle von IT- Projektverträgen weitgehend vermeiden lassen. Die wichtigsten 
Best Practices hierzu werden in der vorliegenden Darstellung zusammengefasst. 

Die mit IT- Projekten verbundenen Risiken sind umso gravierender, je tiefer die IT 
in die Steuerung der betrieblichen Abläufe eingreift. Sie können sogar den Bestand 
des anwendenden Unternehmens bedrohen, wenn dessen Wettbewerbsfähigkeit 
deutlich beeinträchtigt wird, so etwa durch Verlust geplanter Rationalisierungs- 
oder Marktvorteile. Der gesamte produktive Betrieb kann gefährdet sein, wenn 
zum Beispiel die Einführung von sog. „Enterprise Resource Planning“- Software 
scheitert, die alle wesentlichen Geschäftsprozesse hätte steuern sollen, und wenn 
zugleich die alte Anwendung anbieterseits nicht mehr oder nur eingeschränkt 
unterstützt wird. Ein weiteres Risiko ergibt sich aus Defiziten in der unzureichen- 
den technischen Sicherung der jeweiligen Anwendungen, die einerseits die Nutz- 
barkeit des IT-Systems in der gesamten vorgesehenen Nutzungsdauer sicherstel- 
len, und andererseits, oft genauso wichtig, Angriffe von außen auf die betriebliche 
IT abwehren soll. Auch hier muss eine Gestaltung von Verträgen mit Dienst- 
leistern den bestehenden Risiken angemessen Rechnung tragen. Das Herstellen 
und laufende Unterstützen der IT-Sicherheit ist selbst als - oft für den Unterneh- 
mensbestand wesentliches - Projekt zu konzipieren. 

Betrachtet man Fälle gescheiterter IT-Projekte näher, so zeigt sich, dass meist keine 
ausreichende Vorsorge für zeitnahe Projektsteuerung und Absicherung der Anwen- 
dungen in den zugehörigen Projektverträgen getroffen wurde, obwohl sie möglich 
gewesen wäre. Insbesondere werden oft nur Leistungsziele vorgegeben (und auch 
diese nicht selten nur ungenau), nicht aber die Wege zu diesen Zielen mit kontrollfä- 
higen Zwischenschritten im Projektablauf vertraglich definiert. Die vorliegende 
Darstellung soll aufzeigen, welche Regelungspunkte ein IT -Projektvertrag aufweisen 
muss, der zu einer erfolgreichen Projektsteuerung beitragen kann. Die Darstellung 
ist nach den typischen Stufen von IT-Projekten aufgegliedert und diskutiert auf 
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Vorwort 



jeder Stufe Fallstricke und mögliche Vorkehrungen gegen solche Risiken. Berück- 
sichtigt sind die Best-Practice-Vorgaben von ITIL und die hieraus entwickelten typi- 
sierten Regelungsvorschläge in der Norm ISO 20000. Diese in der Praxis entwickel- 
ten V orgaben für Regelungspunkte nicht einzubeziehen, kann einen gravierenden 
Fehler bei der Vertragsgestaltung (und Rechtsberatung) darstellen. 

Die Durchführung von IT-Projekten stellt selbst geradezu ein Musterbeispiel für 
ein Risiko dar, das jede Geschäftsleitung aus ihrer Rechtspflicht früherkennen und 
abwenden oder zumindest begrenzen muss. Mit zunehmender Bedeutung der IT 
für die Steuerung praktisch aller Geschäftsprozesse im Unternehmen steigt das 
Risiko, dass ein Scheitern des jeweiligen Projekts den Bestand des gesamten Un- 
ternehmens gefährden kann (etwa, weil eine notwendige Migration auf andere 
Systemplattformen oder eine benötigte Einführung oder Änderung von unter- 
nehmenssteuernder Software scheitert). Vorsorge gegen diese Risiken kann am 
ehesten (und teilweise überhaupt nur) über einen entsprechend ausverhandelten 
Projektvertrag getroffen werden. Diese vertragliche Projektabsicherung herzustel- 
len gehört zu den wesentlichen Aufgaben der Geschäftsleitung IT- an wendender 
Unternehmen. Für die einzelnen Projektstufen wird deshalb im Text und in 
Checklisten aufgezeigt, welche Kontrollen IT-Projektleiter und Geschäftsleitung 
(auch präventiv) durchzuführen haben. 

Die Mitglieder der Geschäftsleitung haben ein eigenes Interesse am Gelingen des 
IT-Projekts. Wäre nämlich das Scheitern oder die erhebliche Verzögerung eines 
Projekts u. a. durch bessere Vertragsgestaltung und straffe Kontrolle des Projekt- 
fortschritts (bzw. eine schadensträchtige Kompromittierung der IT-Sicherheit 
durch rechtzeitige Kontroll- und Schutzmaßnahmen) und weitere geeignete Maß- 
nahmen im Projektmanagement vermeidbar gewesen, kann das Unterlassen dieser 
Maßnahmen die persönliche Haftung jedes der Mitglieder der Geschäftsleitung 
begründen, wenn und soweit das erforderliche Überwachungssystem zur Risiko - 
früherkennung nicht oder nicht ausreichend eingerichtet und angewendet wurde. 
Die Mitglieder der Geschäftsleitung haften insoweit dem Unternehmen und damit 
den Kapitaleignern auf den Ersatz von Schäden, die durch solche Versäumnisse 
verursacht wurden, müssen also im eigenen Interesse jedenfalls die typischen und 
damit bekannten und vorhersehbaren Fehler bei der Konzipierung und Durchfüh- 
rung von IT-Projekten vermeiden. Die Darstellung enthält in dieser Hinsicht ge- 
wissermaßen ein Pflichtenprogramm für Projektleiter und Mitglieder der Ge- 
schäftsleitung zum richtigen Management von IT-Projekten. Werden die auf der 
Grundlage dieses Pflichtenprogramms getroffenen Maßnahmen außerdem zurei- 
chend dokumentiert, kann dies zugleich eine Entlastung von möglicher persönli- 
cher Haftung wesentlich erleichtern. 



Frank A. Koch 
Frühjahr 2007 
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Vertragsgestaltung für IT-Projekte - zentrale Regelungspunkte 
im Überblick 



Die vorliegende Darstellung orientiert sich am Ablauf typischer IT-Projekte. Diese 
weisen meist folgende Stufen auf: 



• Projektvorschlag und -an trag 

• Anforderungsphase: Interne Bestandsaufnahme der betrieblichen IT, Fest- 
legung benötigter, zu beschaffender IT-Ressourcen und Entscheidung für 
ein Projekt 

• Festlegen der vom Anbieter zu erbringenden Leistungen im Fachkonzept 
(Lastenheft) und IT-bezogenen Konzept (Pflichtenheft) 

• Vereinbarung zu den Leistungsmerkmalen, zu Erweiterbarkeit (Skalierbar- 
keit, Schnittstellen), Terminen und Preisen; Verfahren bei Leistungsände- 
rungen (Mängelbeseitigungen, Zusatzleistungen, Änderungen der vorgege- 
benen Leistungsspezifikationen (d.h. sog. „Moving Targets“ 1 ) im „Change 
Management“ -Verfahren; Sicherung laufender anbieterseitiger Unterstüt- 
zung der Nutzung der Leistungen (Wartung, Pflege) 

• Dokumentation der Anbieterleistungen 

• Qualitätssicherung 

• IT-Sicherheitsmanagement 

• Schulungen 

• Einweisungen 

• Rollout 

• Installationen 

• Abnahme erbrachter Leistungen 

• Mängelrechte des Kunden 

• Vertragsbeendigung 



i 



Streitz, IT-Projekte retten, 3. 
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Vertragsgestaltung für IT-Projekte - zentrale Regelungspunkte im Überblick 



Weiter werden behandelt: 

• Möglichkeiten der Kostensenkung durch Vertragsanpassung 

• Sanierung von IT- Projekten 

• Anwenderrechte bei Insolvenz des Anbieters 

• Outsourcing 

• Application Service Providing 

• Einführung von Enterprise Resource Planning Software 

• Customizing 

• Rechtliche Verantwortlichkeit der Geschäftsführung für die Projektsteue- 
rung 

• ITIL und ISO 20000 als Mittel der Projektsteuerung 

• Checklisten für den IT- Projektleiter und die Geschäftsführung 






A Steuerung von IT-Projekten durch Vertrag 



Der Vertrag muss der Projektgestaltung und -Steuerung dienen und die hierfür 1 
erforderlichen Regelungselemente enthalten. Hierzu muss jeder IT- Projektvertrag 
zwei Komplexe regeln: 

Erstens ist das Ziel der Leistungserbringung zu definieren, also das produktiv 2 
einsetzbare IT-System mit den entsprechenden Komponenten (Software und 
Hardware) und Leistungsdaten (z.B. Verfügbarkeit), Nutzungsrechten, Mängel- 
haftung und Vertragsbeendigung. Gleiches gilt bei reiner Erstellung und/oder 
Anpassung von Software. 

Zweitens muss der Weg der Leistungserbringung „wie ein Regiebuch“ 1 näher 3 
beschrieben und mit zeitnahen Kontrollen der erbrachten Leistungsteile („Mi- 
lestones“) und hierbei eingesetzten Verfahren verknüpft werden, da nur auf diese 
Weise frühzeitig erkannt werden kann, ob sich das Projekt im vorgesehenen Zeit- 
rahmen und auf dem richtigen Weg befindet. 

Regelmäßig zu prüfen ist auch die anbieterseits garantierte Einhaltung von Quali- 4 
tätssicherungsnormen und die Verwendung bestimmter Verfahren der Software- 
Erstellung. Oft kann die Vertragsgemäßheit der erbrachten Leistung nur oder je- 
denfalls frühzeitig nur an der Einhaltung solcher Verfahren abgelesen werden. 2 
Über die Leistungserbringungsprozesse steuern lässt sich ein Projekt aber nur, 
wenn die entsprechenden Anforderungen und deren Kontrollfähigkeit im Vertrag 
ausdrücklich als geschuldete (und zulässig vom Auftraggeber kontrollierbare) Leis- 
tungsmerkmale festgelegt sind (ebenso eine Pflicht zum regelmäßigen Reporting). 
Hierdurch wird auch, zumindest teilweise, vom gesetzlichen Vertragstyp des Werk- 
vertrags abgewichen. Der Anbieter ist nämlich als Werkunternehmer grundsätzlich 
in der Wahl derjenigen Mittel frei, die er zur Vertragserfüllung einsetzt. Die bestel- 
lerseitige Kontrolle dieser Mittel und ihrer Anwendung bedarf damit besonderer 



1 Müller-Hengstenberg, CR 2005, 385, 388. 

2 Nehfort, Qualitätsmanagement für IT-Lösungen, in: Tiemeyer (Hrg.), Handbuch IT- 
Management, 403, 433, bemerkt zutreffend: „Gleichbleibend hohe Qualität erreicht 
man nicht über die Prüfung am Endprodukt, sondern über die Beherrschung der Ent- 
wicklungs- bzw. Fertigungsprozesse“. 
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A. Steuerung von IT-Projekten durch Vertrag 



Vereinbarung. Der Anbieter muss aber, um als Werkunternehmer eingestuft wer- 
den zu können, jedenfalls frei bleiben, unter geeigneten Mitteln zu wählen. Werden 
ihm diese Mittel sowie Erstellungsverfahren (etwa in Programmierrichtlinien) 
hingegen detailliert vom Kunden vorgeschrieben, kann dies dazu führen, dass er 
nicht mehr einen werkvertraglichen Leistungserfolg schuldet, sondern Weisungen 
des Kunden nach Dienstvertragsrecht unterliegt. In solchen Fällen schuldet der 
Anbieter nur das freilich qualifizierte Befolgen dieser Weisungen, nicht aber einen 
Leistungserfolg. Bei der Anwendbarkeit von Werkvertragsrecht wird es aber grund- 
sätzlich auch dann bleiben, wenn der Anbieter zwar in der Mittelwahl frei bleibt, 
jedoch die Wahl dieser Mittel und die Verfahren ihrer Anwendung transparent und 
damit für den Kunden kontrollfähig gestaltet sind. Die Abgrenzung der jeweils 
geschuldeten Leistung in ihrer vertragsrechtlichen Zuordnung kann deshalb nur 
unter Berücksichtigung der Umstände des Einzelfalls (etwa der konkreten Ausges- 
taltung des Vertrags bzw. der Leistungsbeschreibung) erfolgen. 

5 Zeitnahe und phasenorientierte Projektsteuerung durch Vertrag ist bei größeren 
Projekten unabdingbar. Die Einführung und Unterstützung von unternehmens- 
steuernder Software („Enterprise Resource Planning“ Software) ist hierfür ein 
Musterbeispiel. Kaum ein auftraggebendes Unternehmen kann sich nämlich bei 
Auftreten von Konflikten einen jahrelangen Rechtsstreit mit dem Anbieter leisten. 
Hierdurch würde die Einführung der meist dringend benötigten Software auf 
unbestimmte Zeit verzögert und die eigentlich zu verbessernde Wettbewerbsfä- 
higkeit des Auftraggebers im Gegenteil eher geschwächt, da er einen nicht uner- 
heblichen Teil seiner Aufmerksamkeit und Zeit auf den Gerichtsprozess richten 
muss. In der Zwischenzeit bleibt er an das Altsystem gebunden, das u.U. nicht 
einmal mehr während der gesamten Verfahrensdauer vom alten Anbieter weiter 
unterstützt wird (insbesondere nicht, wenn dieser insolvent geworden ist). Die 
Alternative kann nur sein, im Rahmen der erforderlichen Risikovorsorge jeden- 
falls Lösungswege für die wichtigsten typischen Konflikte (sprich: „Leistungsstö- 
rungen“) im Vertrag selbst zu regeln. Das Scheitern von Projekten ist zumeist 
darauf zurückzuführen, dass „rettende“ Regelungen für solche Fälle im Vertrag 
nicht getroffen wurden, obwohl sie in der Verhandlungsphase durchsetzbar gewe- 
sen wären. 

6 Der Projektvertrag selbst muss deshalb in seiner Umsetzung als ein Verfahren 
zur Steuerung des Projekts verstanden und ausgestaltet werden. Das gelingt nur, 
wenn nicht nur die zu erbringenden Leistungsziele kontrollfähig, d.h. ausreichend 
granulär und damit testbar, beschrieben werden, sondern auch die Wege, um diese 
Leistungsziele zu erreichen. 

7 Der Auftraggeber muss beachten, dass Versäumnisse bei der Gestaltung der ver- 
traglichen Regelungen für ihn zu beträchtlichen Nachteilen, nämlich insbesondere 
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Projektverzögerungen und/oder Kostensteigerungen führen können, teilweise 
sogar zum völligen Scheitern eines Projekts (mit allen nachteiligen Folgen für das 
Unternehmen). Waren solche Nachteile für die Mitglieder der Geschäftsleitung 
des auftraggebenden Unternehmens vorhersehbar (wie bei Projektkrisen durchaus 
nicht selten jedenfalls für typische Fehler der Fall), kommt sogar eine persönliche 
Haftung der Mitglieder der Geschäftsleitung in Betracht (auf die unter Randnr. 
608 näher eingegangen wird). 

Anwaltliche Beratung sollte möglichst vor Vertragsschluss beauftragt werden, also 
zu einem Zeitpunkt, zu dem noch vertragliche Gestaltungsmöglichkeiten zur Ab- 
sicherung der jeweiligen Rechtsposition bestehen, nicht erst nach Auftreten von 
Problemen im Projekt oder gar bei dessen Scheitern. Bei komplexeren Projekten 
kann die Hinzuziehung externer Rechtsberatung zu erwägen sein, wenn die zu 
prüfenden Fragestellungen über die regelmäßigen Aufgaben der Rechtsabteilung 
hinausgehen. Solches beauftragtes rechtliches Controlling kann auch dann sinn- 
voll sein, wenn mit vielen Änderungen und Ergänzungen („Changes“) des Pro- 
jektumfangs zu rechnen ist, die in den Projektvertrag einzubinden sind. 




B Stufen der Durchführung von IT-Projekten 



Die Vertragsparteien müssen im ersten Schritt festlegen, was im IT-Projektvertrag 9 
vom Leistungsumfang her konkret als „Projekt“ 1 verstanden werden soll. Geht es 
um anbieterspezifische Leistungen wie die Erstellung oder bloße Anpassung von 
Software nach vom Auftraggeber vorgegebenen Anforderungen oder soll der An- 
bieter auch die Problemanalyse und die Analyse der Geschäftsabläufe durchführen 
und das fachliche Pflichtenheft („Lastenheft“) erstellen, 2 also eigentliche Mitwir- 
kungshandlungen des Auftraggebers übernehmen? Der Begriff „Projektvertrag“ 
legt aus sich heraus keine Entscheidung zwischen diesen Alternativen fest. Drin- 
gend anzuraten ist deshalb beiden Vertragsparteien, die vom Anbieter zu erbrin- 
genden Leistungen genau zu bezeichnen und zu vereinbaren, ebenso, wer welche 
Leistung (spätestens) zu welchem Zeitpunkt zu erbringen hat. 

1 . Anforderungsphase - Feststellen der IT-Anforderungen durch den Kunden 

Der Auftraggeber muss dem Auftragnehmer die Aufgabenstellung vorgeben. 10 
Hierzu muss er zunächst intern klären, welche Probleme er zu lösen hat (Phase der 
Problemanalyse), und hieraus die gewünschte Leistung ableiten (Phase der Anfor- 
derungsanalyse, Requirements -Engineering). Diese Leistung muss der Auftragge- 
ber konkret und durch ihn kontrollierbar beschreiben (Phase der Leistungsbe- 
schreibung). 



1 „Projekt“ ist nach der Qualitätssicherungsnorm EN ISO 9000:2005 Nr. 3.4.3 ein einma- 
liger Prozess, der aus einem Satz von abgestimmten und gelenkten Tätigkeiten mit An- 
fangs- und Endterminen besteht und durchgeführt wird, um ein Ziel zu erreichen, das 
spezifische Anforderungen erfüllt, wobei Zeit-, Kosten- und Ressourcenbeschränkun- 
gen eingeschlossen sind. Nach der allgemeinen Norm DIN 69 901 wird „Projekt“ defi- 
niert als „ein Vorhaben, das im wesentlichen durch Einmaligkeit der Bedingungen in 
ihrer Gesamtheit gekennzeichnet ist wie z.B. Zielvorgabe, zeiüiche, finanzielle, perso- 
nelle oder andere Bedingungen, Abgrenzung gegenüber anderen Vorhaben, projektspe- 
zifische Organisation.“ 

2 In diesem umfassenden Sinn verstehen etwa Ellenberger/Müller, Zweckmäßige Gestal- 
tung von Hardware-, Software- und Projektverträgen, 9, den Projektvertrag. 
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a) Projektvorschlag 

11 Zunächst sollte der Auftraggeber üblicherweise intern (etwa durch den IT-Abtei- 
lungsleiter, Chief Information Officer, CIO) einen Projektvorschlag mit Projekt- 
begründung ausarbeiten lassen. Dieser sollte beinhalten: 3 

• Beschreibung des Projektgegenstands bzw. der Projektidee. 

• Wie sieht der Ist-Zustand aus? 

• Wie ändert sich die Ist-Situation, wenn das Projekt umgesetzt wird? 

• Skizzierung der Projektziele und gegebenenfalls Wirtschaftlichkeitsbeurteilung 
(Kostenanalyse unter Berücksichtigung der erwarteten Nutzungsdauer) bzw. 
Nutzenbetrachtung des Projekts (Erhöhung der Wettbewerbsfähigkeit; allge- 
mein: Strategierelevanz des Projekts). 

• Erste Aktivitätenplanung. 

• Vorgehensmodell (Projektphasen) mit grobem Terminplan (Projektstart und 
-ende) und Projekt-Milestones 4 , so etwa, in zeitlicher Abfolge, Systembeschrei- 
bung (Definition), Entwicklung des Fachkonzepts und des DV-technischen 
Konzepts, Systemrealisierung (Build), stufenweise Umstellung (Rollout) und 
Produktivstart. 5 

• Grober Kostenplan, Aufwands- und Kostenschätzung. 

• Zu erwartende Ergebnisse des Projekts. 

• Rahmenbedingungen für die Projektumsetzung (Risiko- und Qualitätsmanage- 
ment, Änderungs/„Change“ Management). 

• Berichtsplan. 

Ist die Projektidee mit hoher Unsicherheit verbunden, sollte zunächst in einer Vor- 
studie die Machbarkeit in technischer und wirtschaftlicher Sicht geklärt werden. 6 

b) Analysephase 

12 Wird der Projektvorschlag angenommen, ist zunächst (weiterhin unternehmens- 
intern) eine Analyse des Ist-Zustands und der Soll- Anforderungen (Soll-Konzept) 
durchzuführen. 



3 Weitgehend nach: Tiemeyer , Projektmanagement, in: Tiemeyer (Hrg.), Handbuch IT- 
Management, 233, 240f., 245. 

4 Als „Milestones“ werden besonders wichtige Ereignisse eines Projekts bezeichnet, ne- 
ben Start und Ende etwa der Abschluss der Systemanalyse oder der Modul- bzw. Sys- 
temtests, Installation beim und Abnahme durch den Kunden (Koreimann, Grundlagen 
der Software-Entwicklung, 314). 

5 Tiemeyer, Projektmanagement, in: Tiemeyer (Hrg.), Handbuch IT-Management, 233, 
243. 

6 Hindell Hörmannl Müllerl Schmied, Basiswissen Software-Projektmanagement, 33. 
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(1) Ist-Analyse 

Die Ist-Analyse beinhaltet eine Aufnahme des bisherigen Zustands (Ist-Zustand). 13 
Hierfür ist eine Bestandsaufnahme in der Form einer Beschreibung bereits einge- 
setzter IT- Komponenten und bestehender Abläufe mit den erkennbaren Schwach- 
stellen sowie eine Bewertung des Ist-Zustands vorzunehmen. 7 In der Beschrei- 
bung sind u.a. folgende Fragen zu beantworten: 8 

• Welche Geschäftsprozesse (wie z.B. Ausführung eines Fertigungsauftrags, Ab- 
wicklung einer Kundenbestellung 9 ) werden im Unternehmen eingesetzt? 

• Wer ist für diese Prozesse zuständig? 

• Aus welchen Komponenten besteht die IT-Infrastruktur? 

• Welche Clients und Server sind vorhanden? 

• Wie sind diese konfiguriert? 

• Mengengerüst: Wo fallen welche Daten an? Wer erfasst und wer bearbeitet 
welche Daten? Wer erhält welche Auswertungen? 10 Das Mengengerüst legt die 
benötigte Dimensionierung von Speichermedien und Datenleitungen (Daten- 
durchsatz) fest. Erwartbare Zuwächse an Datenmengen sind zu berücksichtigen. 

• Welche Schnittstellen zu anderen internen Anwendungen und zu externen IT- 
Systemen (etwa der Finanzverwaltung) bestehen bzw. müssen ergänzend einge- 
richtet werden? 

• Wie kann man die Prozesse mit Hilfe von Software weiter optimieren? 

• Sind die Software -Lizenzen im Unternehmen einheitlich und unternehmens- 
weit geregelt? Liegt für jeden Arbeitsplatz eine gültige Lizenz vor? Können un- 
genutzte Lizenzen gekündigt werden? 

• Gibt es nicht benötigte Rechner/Lizenzen oder Installationen? 

• Ist das Patch-Management zentral organisiert? 



7 Stahlknecht/ Hasenkamp, Einführung in die Wirtschaftsinformatik, 210. 

8 Teilweise nach Elsässer, ITIL einführen und umsetzen, 35; Stahlknechtl Hasenkamp, 
Einführung in die Wirtschaftsinformatik, 228. 

9 Die Abwicklung der Kundenbestellung kann folgende Aktivitäten umfassen ( Stahl- 
knecht/Hasenkamp , Einführung in die Wirtschaftsinformatik, 228): Bearbeitung der Be- 
stellung einschließlich Rückfragen, Neu- oder Nachbestellung der Ware für das Lager, 
Versanddisposition, Erfassung des Warenausgangs, Auslieferung der Ware mit Liefer- 
schein, Erstellung und Zustellung der Rechnung, Buchung des Rechnungsbetrags in der 
Finanzbuchhaltung, Buchung des Zahlungseingangs, Mahnung und weitere Schritte bei 
Zahlungsverzug des Kunden. 

10 Stahlknecht/ Hasenkamp, Einführung in die Wirtschaftsinformatik, 228. Zum typischen 
Mengengerüst gehören: a) Stammdaten und Änderungsdaten hierzu (z.B. Kunden- 
oder Lieferantenanschriften, Artikel), b) Bestandsdaten (Debitoren-/Kreditoren-/Sach- 
konten, Lagerpositonen, Arbeitszeitkonten), c) Bewegungsdaten (z.B. Kundenaufträge, 
Bestellungen bei Lieferanten, Lagerentnahmen/zugänge, Kunden-/Lieferantenrech- 
nungen, Zahlungseingänge/-ausgänge, Mahnungen). 
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14 Die Bewertung des Ist-Zustandes soll aufzeigen, welche Schwachstellen die Nut- 
zung der betrachteten Anwendung einschränken. Typische Schwachstellen kön- 
nen sein: zu späte Rechnungsstellung, häufige Differenzen in der Buchhaltung, 
hohe Durchlaufzeiten in der Fertigung und lange Lieferzeiten im Vertrieb. 11 Die 
Auswirkungen auf die Geschäftsprozesse sind aufzuzeigen. 

(2) Reorganisation, Anforderungs- bzw. Systemspezifikation, Sollkonzept 

15 Zunächst muss der Auftraggeber intern bei der Ist- Analyse erkannte Probleme 
analysieren, z.B. eine unzureichend effiziente Bearbeitung eingehender Kunden- 
aufträge, die etwa mit der wiederholten (und damit unnötig zeit- und kostenauf- 
wendigen) Aufnahme der Kunden- und Bestelldaten auf den verschiedenen Stufen 
der Auftragsabwicklung oder zu später Rechnungsschreibung verbunden sein 
kann, die wiederum zu einer zu starken Kapitalbindung durch hohen Lagerbe- 
stand führt. 12 Ergebnis dieser Analyse wird sein, dass diese Abläufe zu optimieren 
sind. Anzusetzen ist hier zunächst bei der Reorganisation der betrieblichen Abläu- 
fe. Auch können etwa zunächst die Formate z.B. der Kundendaten zu vereinheitli- 
chen sein, damit sie durchgängig bearbeitet werden können. Der Einsatz von IT 
kann diese Optimierung nicht ersetzen, da IT-Einsatz nur ein Hilfsmittel, nicht 
aber ein Ziel ist. 13 Die Problemanalyse (und eine durchzuführende Umorganisati- 
on) fällt in den Verantwortlichkeitsbereich des Auftraggebers, wenn sie nicht ge- 
sondert als (etwa von einem Berater oder dem Anbieter zu erbringende) Leistung 
beauftragt wurde. 

16 Von der Problemanalyse her ist im nächsten Schritt zu untersuchen, welche (fach- 
lichen) Anforderungen an ein IT-System bestehen, das diese Optimierung von 
Geschäftsprozessen 14 unterstützen kann (Anforderungsanalyse 15 , sog. „Require- 
ments Engineering“ 16 bzw. „Requirements Management“ 17 ). Von entscheidender 
Bedeutung für die Definition der Anforderungen ist die möglichst vollständige 



11 Stahlknecht I Hasenkamp, Einführung in die Wirtschaftsinformatik, 242. 

12 Stahlknecht/ Hasenkamp, Einführung in die Wirtschaftsinformatik, 243. 

13 Heuscheie, Sanierung von EDV-Projekten, CR 1988, 591, 592. 

14 Ein „Geschäftsprozess“ sei hier verstanden als eine Menge miteinander verknüpfter 
Aktivitäten, welche in einer bestimmten Reihenfolge ausgeführt werden, um ein festge- 
legtes Ziel zu erreichen (Hansen/ Neumann, Wirtschaftsinformatik I, 245). Beispiele für 
Geschäftsprozesse (Business Processes) sind etwa die Ausführung von Kundenaufträ- 
gen, die Bearbeitung einer Kundenreklamation oder von Kreditanträgen in einer Bank 
(Stahlknechtl Hasenkamp, Einführung in die Wirtschaftsinformatik, 207). 

15 Eine „Anforderung“ ist eine Bedingung oder eine Fähigkeit, die ein Benutzer benötigt, 
um ein Problem zu lösen oder ein Ziel zu erreichen (IEEE 1990; Ebert, Systematisches 
Requirements Management, 11). 

16 Hansen/ Neumann, Wirtschaftsinformatik I, 247; Ebert, Systematisches Requirements 
Management, 11 ff. 

Ebert, Systematisches Requirements Management, 12. 
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Erfassung und möglichst eindeutige sowie konsistente Formulierung der Anforde- 
rungen. 18 Typischer Schwachpunkt vieler I I - Projekte ist, dass nur die funktiona- 
len Anforderungen hinreichend präzise spezifiziert wurden, während die nicht- 
funktionalen Anforderungen eher vage blieben. 19 Funktionale Anforderungen 
beziehen sich auf die einzelnen Funktionen der Geschäftsprozesse oder sonstiger 
Anwendungen. Nichtfunktionale Anforderungen (Qualitätsattribute) sind z.B. 
Zuverlässigkeit und Benutzbarkeit. 20 Diese Kategorien müssen erst operationali- 
siert werden, um eine Überprüfung der Vertragserfüllung durch Tests zu ermögli- 
chen. 21 Auch nichtfunktionale Anforderungen müssen also messbar und binär 
entscheidbar (entscheidbar als „nichterfüllt“ oder „erfüllt“) sein, damit ihre Ein- 
haltung überprüft werden kann. 22 Wesentlich ist außerdem die Unterscheidung 
zwischen Anforderungen (zu beschreiben aus der Nutzersicht im Fastenheft) und 
Lösungen (zu beschreiben aus der Anbietersicht im IT-Pflichtenheft). Nur die 
Lösungen beschreiben die exakte Implementierung. 23 

Die Erstellung der Anforderungsanalyse ist Sache des Bestellers (Auftraggebers). 24 17 
Jedoch wurde der Auftragnehmer als verpflichtet angesehen, hierbei insoweit 
mitzuwirken, als er von sich aus die innerbetrieblichen Bedürfnisse, Wünsche und 
Vorstellungen ermitteln, für ihn erkennbare Unklarheiten aufklären, bei der For- 
mulierung der Bedürfnisse mitwirken und Organisationsvorschläge unterbreiten 
müsse. 25 Dies wird aber nur dann gelten können, wenn der Auftragnehmer An- 



18 Hindell Hörmannl Müllerl Schmied, Basiswissen Software-Projektmanagement, 4L 

19 Ebert, Systematisches Requirements Management, 13. 

20 ISO/IEC 9126 führt u.a. folgende nichtfunktionale Eigenschaften an: 

Interoperabilität (Fähigkeit, mit vorgegebenen Systemen zusammenzuwirken), 
Ordnungsmäßigkeit (Erfüllung anwendungsspezifischer Normen, Vereinbarungen, 
gesetzlicher Bestimmungen etc.), 

(Daten-)Sicherheit, 

Zuverlässigkeit (Fähigkeit der Software, ihr Leistungsniveau unter festgelegten Be- 
dingungen über einen festgelegten Zeitraum zu bewahren), 

Benutzbarkeit (Verständlichkeit, Erlernbarkeit und Bedienbarkeit), 

- Effizienz (Verhältnis zwischen dem Leistungsniveau der Software und dem Umfang 
der eingesetzten Betriebsmittel unter festgelegten Bedingungen, das Zeitverhalten 
und das Verbrauchsverhalten der benötigten Bedingungen), 

- Änderbarkeit (Aufwand, der zur Durchführung von Änderungen wie Korrekturen, 
neue Funktionen notwendig ist), 

Portierbarkeit (Aufwand, die Software in eine andere Umgebung zu verlagern, dort 
zu installieren, anzupassen oder Teile auszutauschen). 

21 Ebert , Systematisches Requirements Management, 13. 

22 Ebert , Systematisches Requirements Management, 103, 109. 

23 Ebert , Systematisches Requirements Management, 13, 17. 

24 OLG Köln, Urt.v.29.7.2005 - 19 U 4/05, JurPC Web-Dok. 16/2006; OLG Köln NJW-RR 
1995, 51f; 1993, 1529f. 

OLG Köln, Urt.v.29.7.2005, a.a.O. 



25 
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haltspunkte dafür hat, dass eine solche Mitwirkung (insbesondere, wenn sie kos- 
tenpflichtig sein soll) erwünscht und erforderlich ist. Der Anbieter wird freilich 
von vornherein mit gewissen Unsicherheiten der Auftraggeber rechnen und „nä- 
her hinschauen“ müssen, ob Anzeichen für Lücken, Widersprüche oder falsche 
technische Vorstellungen erkennbar sind. Grundsätzlich müssen Anforderungen 
vollständig, korrekt, konsistent, testbar, verständlich, notwendig, eindeutig und 
umsetzbar 26 , entscheidbar und in einer einheitlichen Basis zusammengefasst 
sein 27 und auch durch alle Änderungen hindurch bleiben. Der Anbieter muss 
insbesondere darauf dringen, dass die Anforderungen bzw. Projektziele sauber 
formuliert werden; unvollständige Anforderungsbeschreibungen stellen immerhin 
einen Hauptgrund für das Scheitern von IT-Projekten dar. 28 Ein weiterer wesentli- 
cher Grund sind unkontrollierte Änderungen von Anforderungen; 29 dies gilt um- 
so mehr, als sich Anforderungen mit einer monatlichen Rate ändern, die zwei bis 
fünf Prozent des gesamten Projektaufwandes betragen kann. 30 Dies erfordert ein 
Änderungsmanagement (in der Form des Change Managements), da ad hoc und 
unkontrolliert erfolgende Änderungen Projektkontrolle wie allgemein jedes Kon- 
figurationsmanagement unmöglich machen. 31 Auch sind schon in der Entwurfs- 
phase mögliche Vorkehrungen gegen Änderungs“risiken“ zu treffen. Weist eine 
instabile Anforderung ein hohes Projektrisiko auf (wenn sich z.B. eine vorgegebe- 
ne Architektur ändern könnte), sollte das Design der Lösung so aufgesetzt werden, 
dass die Änderung bestmöglich abgefangen werden kann („design for change“)- 32 
Schließlich muss die Realisierung der Anforderungen (und ihrer Änderungen) 
kontrolliert und verfolgt werden, um den Projektfortschritt zu erkennen. Dieser 
Statusreport ist unmittelbar auch für die Geschäftsleitung relevant, um zu erken- 
nen, ob sich das Projekt im geplanten Korridor bewegt und steuerbar bleibt. Nur 
unterstrichen werden kann der Grundsatz: „Ein gutes Projekt beherrscht die Än- 
derungen und wird nicht von ihnen beherrscht .“ 33 

18 Ausgehend von den Schwachstellen und Anforderungen der Geschäftsprozesse ist 
ein Sollkonzept zu entwickeln. Es muss Aussagen darüber enthalten, was das An- 
wendungssystem fachlich leisten soll (abzubilden im Lastenheft) und welche tech- 
nischen Anforderungen es zu erfüllen hat (abzubilden im IT-Pflichtenheft). Im 
Fachkonzept sind alle im Zusammenhang stehenden Geschäftsprozesse mit einzu- 
beziehen. Nicht ausreichend ist nur eine allgemeine Aufzählung. Vielmehr müssen 



26 Ebert, Systematisches Requirements Management, 39. 

27 Ebert, Systematisches Requirements Management, 108. 

28 Ebert, Systematisches Requirements Management, 23, 24. 

29 Ebert, Systematisches Requirements Management, 28. 

30 Ebert, Systematisches Requirements Management, 43. 

31 Ebert, Systematisches Requirements Management, 68. 

32 Ebert, Systematisches Requirements Management, 77. 

33 Ebert, Systematisches Requirements Management, 184. 
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die Abläufe aus der fachlichen Sicht möglichst genau beschrieben werden. Die 
scheinbar einfachen Prozesse zeigen nämlich bei der Implementierung schnell, wie 
komplex sie sein können. Dies lässt sich am Beispiel der Auftragsbearbeitung gut 
verdeutlichen. So muss es etwa möglich sein, einem Besteller eine vorhandene 
Kundennummer zuzuordnen, wenn der Besteller bereits früher Bestellungen getä- 
tigt hat. Weiter muss die Bearbeitung des Auftrags auch dann möglich sein, wenn 
nur ein Teil der bestellten Produkte vom Lager ausgeliefert werden kann und der 
Rest erst nach Anlieferung durch den Zulieferer. Soll der Kunde den Weg seiner 
Bestellung in ihrer Bearbeitung internetgestützt mitverfolgen können, muss dies 
zusätzlich implementiert und gegen unberechtigte Zugriffe (oder gar unberechtig- 
te Änderungen) abgesichert werden. 34 

Zu beachten ist, dass aus der Sicht der Fachbereiche Perspektivenverkürzungen 19 
auftreten können. Fachbereiche sollen nämlich dazu neigen, nur eigene Teilpro- 
zesse zu betrachten und vor- oder nachgelagerte Prozesse nicht ausreichend zu 
berücksichtigen. 35 Allgemein sollten Insellösungen vermieden bzw. nicht in neue 
Anwendungen „hinübergerettet“ werden dürfen, da hierdurch überproportional 
hohe Zusatzkosten verursacht werden können. 

Der Auftragnehmer ist nicht gehalten, von sich aus ohne gesonderte Vereinbarung 20 
die fachlichen Anforderungen des Auftraggebers zu untersuchen, es sei denn, der 
Auftraggeber muss dem Anbieter darüber aufklärungsbedürftig erscheinen, dass 
er erkennbar keine oder falsche Vorstellungen zu IT-relevanten Organisationsvor- 
aussetzungen hegt 36 oder seine Vorstellungen zusätzliche Investitionen in die IT- 
Infrastruktur erfordern. Diese Aufklärungs- und Hinweispflicht steht auch dem 



34 Stahlknecht/ Hasenkamp, Einführung in die Wirtschaftsinformatik, 228, zeigen die 
Verästelungen von Geschäftsprozessen in der Praxis auf, die von Standardanwendun- 
gen nicht selten nur unzureichend abgedeckt werden. Hiernach umfasst etwa der Ge- 
schäftsprozess „Abwicklung einer Kundenbestellung“ bei Nachfakturierung folgende 
Aktivitäten: „Bearbeitung der Bestellung einschließlich Rückfragen, Neu- oder Nachbe- 
stellung der Ware für das Lager, Versanddisposition, Erfassung des Warenausgangs, 
Auslieferung der Ware mit Lieferschein, Erstellung und Zustellung der Rechnung, Bu- 
chung des Rechnungsbetrags in der Finanzbuchhaltung, Buchung des Zahlungsein- 
gangs, Mahnung und weitere Schritte bei Zahlungsverzug des Kunden.“ Wird dieser 
Aktivitätenkatalog nun programmiert, sind Fälle wie kundenseitige Zurückbehaltung 
der Zahlung bei Lieferung mangelhafter Produkte, Verrechnung mit Guthaben oder 
Vertragsstrafen, etc. noch gar nicht erfasst. 

35 Dietrich/ Schirra, IT im Unternehmen, 58, mit dem Beispiel schnell entwickelter, aber 
insulär bleibender Auswertungen auf Excel- oder Lotus Notes-Basis, die verhindern, 
dass Geschäftsprozesse durchgängig dargestellt werden können. 

OLG Hamm, Urt.v. 23.11.1988 - 31 U 63/88, BB Beilage 15/1989, 3. 



36 
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Rat gegenüber, der Anbietern aus der Perspektive des Projektmanagements gege- 
ben wird, nämlich dem Kunden zu geben, was er will und nicht, was er braucht . 37 

21 Von Anbietern von ERP-Software wird teilweise angeboten, zunächst die Ge- 
schäftsprozesse nach einem anbieterspezifischen Geschäftsmodell neu zu gestalten 
und standardisiert als Sollkonzept zu modellieren. Anhand des Sollkonzepts ist 
dann jeweils zu entscheiden, ob die Arbeitsabläufe an die Standardsoftware anzu- 
passen sind oder umgekehrt die Standardsoftware an die Abläufe , 38 im letzteren 
Fall möglichst durch Parametrisieren und nur im Einzelfall durch zusätzliche 
Individualprogramme (während der Code des eigentlichen Programms unverän- 
dert bleiben soll ). 39 

c) Entscheidung über das IT-Projekt 

22 Nach der Anforderungsanalyse ist eine Entscheidung über das IT-Projekt zu treffen. 
Dieses kann intern durchzuführen sein oder extern durch Beauftragung von Anbie- 
tern. Für die Entscheidung über das Ob eines IT-Projekts und seine Dimensionie- 
rung sind auch Fragen zu prüfen, die im Zusammenhang mit dem anwendenden 
Unternehmen stehen : 40 

• Ist das Projekt wirklich für das Unternehmen wichtig? Rechnet sich der erfor- 
derliche Aufwand? In welchem Zeitrahmen? 

• Was wird das Projekt ändern? 

• Welche Auswirkungen hat das Projekt auf die Organisation, die Ressourcen 
und die Wirtschaftlichkeit des Unternehmens? Ist es wirklich an die betrieb- 
lichen Erfordernisse angepasst? 

• Welche Kosten sind für das Unternehmen vertretbar? Wo ist die kritische 
Schwelle bei Kostensteigerungen? 

• Wie wahrscheinlich ist der Eintritt einer nicht vertretbaren Kostensteigerung? 
Gibt es für diesen Fall eine „Exit“-Strategie? 

• Was passiert, wenn das Projekt abgeschlossen wird? 

23 Individualentwicklungen von Software sollten nur im Ausnahmefall beauftragt 
(bzw. selbst in Angriff genommen) und statt dessen (soweit wie möglich) Anpas- 
sungen vorhandener Programme vorgezogen werden. Dietrich 41 findet hier ein- 
deutige Worte: Er weist darauf hin, dass „Software-Produzenten eine Software 
mehrere hundert Mal verkaufen müssen, um einen positiven Return on Invest- 



37 So explizit: Ebert , Systematisches Requirements Management, 69. 

38 Stahlknecht/ Hasenkamp, Einführung in die Wirtschaftsinformatik, 306. 

39 Stahlknecht I Hasenkamp, Einführung in die Wirtschaftsinformatik, 307. 

40 Teilweise nach Müller-Hengstenberg, CR 2005, 385, 387; Ebert, Systematisches Requi- 
rements Management, 87f. 

41 Dietrich/ Schirra, IT im Unternehmen, 59/60. 
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ment (ROI) zu erhalten. Wie kann ein Unternehmen glauben, einmalige Entwick- 
lungen wirtschaftlich umzusetzen? Eigene Software-Entwicklung sollte definitiv 
auf solche Ausnahmen beschränkt bleiben, bei denen es entweder nachweislich 
keine Standardsoftware im Markt gibt oder ein signifikanter strategischer Vorteil 
erzielbar ist“. 

(1) Projekttyp 

Bei der Entscheidung über ein IT-Projekt ist zugleich der Projekttyp festzulegen. 24 
IT-Projekte können unterschiedliche Inhalte haben. In der IT-Literatur werden 
verschiedene Typen von IT-Projekten (jeweils mit den wichtigsten Projektstufen) 
unterschieden: 42 

Software-Entwicklungsprojekte: 

Ist- Aufnahme und Bedarfsermittlung (Anforderungsspezifikation) 

Grobplanung der Lösung 

Pilotrealisierung 

Test und Abnahme 

Software-Einführungsprojekte 

Projektierung 

Fachkonzept 

Design 

Realisierung (Build) 

Test 

Technische Implementierung und Integrationstest 
Organisatorische Implementierung (Run) 

IT-Infrastrukturprojekte 

Projektvorbereitung 

Ist-Analyse 

Zielplanung 

Sollkonzeption 

Pilotanwendung 

Evaluierung der Pilotanwendung 
Umsetzung des Gesamtkonzepts 
Schulung und Gesamtevaluation 



42 Nach: Tiemeyer, Projektmanagement, in: Tiemeyer (Hrg.), Handbuch IT-Management, 
233,261. 
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Netzwerkprojekte 

Projektplanung 

Konzepterstellung 

Vorbereitung 

Durchführung 

Nachbereitung 

Weiter findet sich die Unterscheidung zwischen Entwicklungsprojekten (klassi- 
sche (Eigen-)Entwicklung von IT-Lösungen), Migrationsprojekten (Ablösung 
alter Software und Überführung in neue Software), Sanierungsprojekten (Nach- 
besserung bestehender Lösungen), Integrationsprojekten (Einführung von Stan- 
dardsoftware in hochintegrierten Bereichen) und Strategieprojekten (Entwicklung 
und Überarbeitung von IT-Strategien in Abstimmung mit Unternehmensstrate- 
gien). 43 Grundlegend ist schließlich die Unterscheidung von Projektgeschäft (Ent- 
wicklung und Wartung/Pflege von Anwendungen), IT-Betrieb (Rechenzentren, 
Serverfarmen, Netze) und Service (Betreuung von PCs und anderen Endgeräten). 44 
Für jeden dieser Projekttypen kommt eine spezifische Kombination von Leistun- 
gen und damit Vertragstypen in Betracht. 

(2) Projektstufen 

25 Bevor ein IT-Projekt beauftragt wird, sollte der Auftraggeber grundsätzlich fol- 
gende Feststellungen zu den Projektstufen treffen: 45 

Vertragentwicklungsphase (erste Überlegungen zum Projekt): 

• Ziel des Projekts? 

• Größenordnung des Projekts, betriebswirtschaftliche Auswirkungen auf Betrieb 
und Mitarbeiter (z.B. Qualifikation und Schulungsaufwand)? 

• Umfang der Veränderungen im Betrieb? Neugestaltung von Geschäftsprozes- 
sen? Ablösung veralteter Techniken und/oder Anwendungssysteme? 

• Finanzrahmen für das Projekt, gerade im Hinblick auf Überschreitung des ge- 
setzten Finanzrahmens? 

• Handelt es sich um ein neuartiges Projekt bzw. um neue Technologien, für die 
es keine Referenzen gibt? 

• Was bedeutet ein Abbruch des Projekts? 

• Gibt es Alternativkonzepte, z.B. kleine oder große Lösung? 

• Welches sind die kritischen Bereiche („critical path“)? 



43 Seibold , IT-Risikomanagement, 172. 

44 Dietrich/ Schirm, IT im Unternehmen, 7. 

45 Müller-Hengstenberg, CR 1999, 789, 794; Stahlknecht/ Hasenkamp, Einführung in die 
Wirtschaftsinformatik, 223. 
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Vor Beginn der Projektdurchführung ist zu prüfen: 

• Liegt eine detaillierte Beschreibung der Leistungen vor? 

• Ist die Leistung technisch machbar? (Liegt eine Machbarkeitsstudie vor?) 

• Stehen hierzu qualifizierte Mitarbeiter beim Auftragnehmer und auch beim 
Auftraggeber zur V erfügung? 

• Werden Neuentwicklungen bzw. neue Technologien eingesetzt? 

• Welche Finanzmittel stehen zur Verfügung? 

• Welche Vertragsart, welches vertragliches Risiko ist gefordert? Ist der Vertrag 
im Hinblick auf Leistungsumfang, technische Möglichkeiten, Ressourcen und 
Risiken für den Auftragnehmer zumutbar? (Wenn nein, muss mit Verzögerun- 
gen, Qualitätseinbußen und/oder deutlichen Mehrkosten bei Sonderwünschen 
oder bei Wartung/ Pflege gerechnet werden.) 

• Ist ein Change-Management-Prozess implementiert? Dieser sichert einen ge- 
ordneten Ablauf der Entscheidung über Änderungen. 

• Liegt ein Dokumenten-Managementsystem vor? Bei größeren (oder mehreren 
parallelen) Projekten kann dies allein schon für die Verwaltung der Vertragser- 
gänzungen, Abnahmeprotokolle und Mängelmitteilungen hilfreich sein. 

d) Leistungsbeschreibung 

Grundlage der nach der Entscheidung für das IT-Projekt erforderlichen Beauftra- 26 
gung eines Anbieters muss eine Leistungsbeschreibung sein. (Dies gilt freilich auch 
für interne Projekte.) Für IT-Projekte wird in der Praxis unterschieden zwischen dem 
fachlichen Konzept, das vom Kunden zu erarbeiten ist, und dem DV-technischen 
Konzept, das der Anbieter erstellt. Die Folge dieser (nachfolgend zu erläuternden) 
Aufteilung ist, dass hier der Anbieter einen Teil der Leistungsbeschreibung selbst 
übernimmt, damit aber auch einen Teil der Festlegung, was als Leistung geschuldet 
sein soll. 

Inhaltlich sollte eine Leistungsbeschreibung grundsätzlich möglichst alle relevan- 27 
ten Leistungsteile erfassen und konkret regeln. Nur in dem Umfang, in dem eine 
solche präzise Leistungsbeschreibung erfolgt, können die Vertragsparteien in ei- 
nem Rechtsstreit eine vereinbarte Beschaffenheit behaupten 46 (§ 633 Abs. 2 S. 1 
BGB) und unter Beweis stellen (der Kunde, um deren Nicht- oder Schlechterfül- 
lung zu behaupten, der Anbieter demgegenüber, um die vertragsgemäße Erfüllung 
darzulegen), während Beweisrisiken bezüglich der vertraglichen vorausgesetzten 
Verwendung (§ 633 Abs. 2 S. 2 Nr. 1 BGB) und erst recht bezüglich der gewöhnli- 
chen Verwendung (§ 633 Abs. 2 S. 2 Nr. 2 BGB) auftreten können. 



46 



Schneider/v. Westphalen, Software-Erstellungsverträge, C Rdn. 82 f. 
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28 Zutreffend wurde daraufhingewiesen, dass auch anbieterseitige Leistungsbeschrei- 
bungen transparent ausgestaltet sein müssen; andernfalls können sie wegen unzu- 
reichender Klarheit oder Verständlichkeit unwirksam sein (§ 307 Abs. 3 S. 2 i.V.m. 
Abs. 1 S. 2 BGB). 47 Allerdings wird diese gesetzliche Sanktion nicht für Lasten - 
/Pflichtenhefte gelten, die projektspezifisch individuell (und nicht selten erst nach 
Vertragsschluss) erstellt werden, also keine AGB darstellen (und zwar auch nicht bei 
Erstellung durch den Anbieter). Außerdem greift die Sanktion ohnehin nicht für 
kundenseits erstellte Leistungsfestlegungen, es sei denn, sie sind Teil von Einkaufs- 
AGB oder Ausschreibungsunterlagen. Dennoch sollte natürlich auch insoweit 
Transparenz angestrebt werden, da das Risiko von (jedenfalls für den Anbieter nicht 
erkennbaren) fachlichen Unvollständigkeiten oder Widersprüchen grundsätzlich 
zulasten des Auftraggebers ausgeht. § 307 Abs. 1 S. 2 BGB gilt auch für (versteckte) 
Preisbestimmungen. 48 Bei Unklarheit gilt die für den Vertragspartner günstigere 
Auslegung 49 , was insbesondere bei Sonderwünschen/Mehrleistungen wichtig sein 
kann. Das Bestehen einer Unklarheit genügt nicht, sie muss vielmehr zu einer Be- 
nachteiligung führen. Mit der Verletzung des Transparenzgebotes ist aber i.d.R. die 
Gefahr einer sachlichen Benachteiligung verbunden 50 und kann insoweit keine Ein- 
beziehung der AGB-Klausel in den V ertrag erfolgen. 51 

29 Die Leistungsbeschreibung (gleich, ob als Lasten-/Pflichtenheft oder als Auflistung 
unmittelbar im Vertrag) muss so detailliert gestaltet sein, dass der Auftraggeber 
Position für Position durchprüfen und so kontrollieren kann, ob der Anbieter die 
jeweils geschuldete Leistung erbracht hat. Auch der Auftragnehmer muss Interesse 
an einer solchen Leistungsbeschreibung haben, da sie nicht nur festlegt, was er zu 
leisten hat, sondern auch, was nicht mehr zum Leistungsumfang gehört und des- 
halb nur als zusätzlich zu vergütende Leistung erbracht zu werden braucht. Die 
Feststellungen aus dem Soll-Status sind in die Leistungsbeschreibung aufzuneh- 
men, soweit die Leistungen vom Anbieter zu erbringen sind. Vom Auftraggeber zu 
erbringende Mitwirkungsleistungen sind getrennt hiervon im Vertrag oder in einer 
Anlage zu diesem festzuhalten; der Auftragnehmer sollte hier im eigenen Interesse 
diese Mitwirkungshandlungen möglichst klar bezeichnen, wenn er später etwa 
deren Nichterbringung behaupten muss. 

30 In der Leistungsbeschreibung sollten auch bereits präzise bezeichnete Termine 
(genaues Datum!) für den Abschluss der verschiedenen Leistungsstufen festgelegt 
werden. Diese Festlegung kann aber auch noch nach Vertragsunterzeichnung 



47 Schneider/v. Westphalen, Software-Erstellungsverträge, C Rdn. 83. 

48 Zieglerl Rieder, ZIP 2001, 1789, 1792 

49 Zieglerl Rieder, a.a.O. 

50 BGHZ 136, 394, 401; Palandt /Heinrichs, § 307 Rdn. 20. 
Palandt/Heznnc/is, § 307 Rdn. 16. 



51 
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erfolgen. Hier sollten die Vertragsparteien jedoch im Vertrag regeln, dass die 
nachträgliche Terminvereinbarung nachträglich erfolgt und als Änderung des 
Vertrages schriftlich zu erfolgen hat und von beiden Seiten zu unterzeichnen ist. 
Nur auf der Grundlage eines verbindlich vereinbarten Termingerüsts kann der 
Kunde Rechte aus Verzug ohne Schwierigkeiten geltend machen. Fehlen solche 
Vereinbarungen, muss der Kunde erst Frist setzen und hierbei das Risiko einge- 
hen, dass die von ihm gesetzte Frist unangemessen, da zu kurz ist. Andererseits 
kann auch der Anbieter seine Projektplanung nur erschwert durchführen, wenn 
klare zeitliche Vorgaben fehlen. 

e) Lastenheft und Pflichtenheft als Formen der Leistungsbeschreibung 
(1 ) Erstellen der fachlichen Anforderungen (Lastenheft) 

Terminologisch ist vorab zu beachten, dass in der Rechtsprechungspraxis 52 
häufig bereits das Lastenheft als „Pflichtenheft“ bezeichnet wird , 53 während in 
der IT-Praxis die fachlichen Anforderungen im „Lastenheft“ 54 , die DV- 
technische Lösung aber im „Pflichtenheft“ erfasst werden . 55 Nach dem Sprach- 
gebrauch der Rechtsprechung muss der Auftraggeber grundsätzlich im Pflich- 
tenheft die fachliche Spezifizierung beschreiben , 56 der Anbieter die Lösung in 
einem DV-technischen Konzept. Die Abweichung der Rechtsprechung vom 
Sprachgebrauch der IT-Praxis ändert also nichts daran, dass der Auftraggeber 
grundsätzlich nur die fachlichen Vorgaben zusammenzustellen hat 57 (wenn er 
nicht selbst DV-Kompetenz aufweist, z.B. als Systemhaus, und deshalb die Leis- 
tungsbeschreibung fachlich und technisch komplett erstellt) und der Auftrag- 
nehmer verpflichtet bleibt, die technischen Vorgaben auf der Basis des Lasten-/ 
Pflichtenhefts zu erarbeiten (wenn er nicht zusätzlich mit der Erstellung des 
fachlichen Pflichtenhefts = Lastenhefts beauftragt wird). 



52 BGH, Urt.v.24.9.1991 - X ZR 85/90, CR 1992, 543 - Zugangskontrollsystem (den Auf- 
traggeber zur Pflichtenhefterstellung verpflichtet ansehend). 

53 Schneider/v. Westphalen, Software-Erstellungsverträge, C Rdn. 18f. 

54 Das „Lastenheft“ beinhaltet nach DIN 69901 die Gesamtheit der Anforderungen des 
Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers, das „Pflich- 
tenheft“ die ausführliche Beschreibung der Leistungen, die erforderlich sind oder gefor- 
dert werden, damit die Ziele des Projekts erreicht werden. Die DIN-Norm nimmt keine 
Zuordnung der Verantwortlichkeiten vor ( Miiller-Hengstenberg , Der Vertrag als Mittel 
des Risikomanagements, CR 2005, 385, 390). 

55 So etwa grundlegend die VDI-Richtlinie 2519 Blatt 1 - Vorgehensweise bei der Erstel- 
lung von Lasten-/Pflichtenheften. 

56 OLG Köln, Urt.v.7.2. 1 992 - 1 9 U 1 1 7/9 1 , CR 1 992, 470. 

57 Schneider/v. Westphalen, Software-Erstellungsverträge, C Rdn. 37. 
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32 Vorsorglich sollte im IT-Projektvertrag definiert werden, was die Vertragspartei- 
en unter den Begriffen „Pflichtenheft“ und ggf. „Lastenheft“ verstehen wollen. 
Hieran ist dann grundsätzlich auch ein Gericht gebunden. 

33 Der Auftraggeber muss (in eigener Verantwortlichkeit 58 , wenn der Anbieter diese 
Erstellung nicht aufgrund besonderer Vereinbarung schuldet) vor Erteilung eines 
Auftrags an Anbieter zunächst in einer Bestandsaufnahme prüfen, welche fachli- 
chen Probleme gelöst, also z.B. betriebliche Prozesse eingerichtet oder verbessert 
werden müssen. Einige dieser Probleme lassen sich unmittelbar, also unabhängig 
von der IT, lösen, etwa durch Änderungen in der Organisation der betrieblichen 
Abläufe, andere durch Auslagern von Prozessen auf beauftragte Unternehmen. 
Am Ende dieser fachlichen Analyse und Reorganisation muss ein komplettes Bild 
aller durch IT zu unterstützenden Geschäftsprozesse in ihrer definitiven Gestalt 
stehen. 

Ist-Analyse 

34 Zu beginnen ist mit der erwähnten Ist-Analyse. Hierbei sind Abläufe (Geschäfts- 
prozesse) ganz konkret, d.h. in Teilprozesse zergliedert, zu betrachten, etwa die 
Bearbeitung einer Artikelbestellung von der Annahme des Auftrages einschließ- 
lich Aufnahme der Kundendaten über die Bearbeitung in der Lagerverwaltung 
(Bereitstellen des Produkts) oder in der Produktion (Herstellen des Produkts) bis 
zur Auslieferung einschließlich der Fakturierung. Einerseits ist darauf zu achten, 
dass auf den verschiedenen Stufen der Auftragsbearbeitung dieselben Kunden- 
und Produktdaten nicht erneut (gar manuell) eingegeben werden müssen, son- 
dern übernommen werden können. Andererseits muss festgelegt werden, mit 
wievielen derartigen Aufträgen pro Zeiteinheit (Tag/Woche/Monat/Quartal) zu 
rechnen ist und in der näheren Zukunft bei Nachfragesteigerungen zu rechnen 
sein wird (um Reserven im Mengengerüst festzulegen). Zu fragen ist, wie häußg 
bestimmte Teilaufgaben durchgeführt werden, welche Daten einzugeben sind und 
ausgegeben werden, welche Verarbeitungsschrittte jeweils erfolgen, welche Ent- 
scheidungsregeln anzuwenden sind und welche Ausnahmefälle auftreten können. 
Für alle verwendeten Formulare und Belege sind die Datenfelder mit Bezeichnung 
von Inhalt und Länge, Sortierkriterien, Nummernsysteme (z.B. Identnummern), 
Aufbewahrungsfristen, etc. festzuhalten. Zu klären ist, welche Geschäftsprozesse 
mit (kostengünstigerer) Standardsoftware in welchem Umfang abgedeckt werden 
können . 59 

35 Aus diesen Vorgaben ist ein Mengengerüst zu erstellen, das zur Bestimmung der 
erforderlichen IT-Ressourcen wesentlich ist. Hierzu gehören Feststellungen zur 



58 BGH, Urt.v.24.9.1991 - X ZR 85/90, CR 1992, 543 - Zugangskontrollsystem. 

59 Streitz, IT-Projekte retten, 29. 
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Anzahl der (Bildschirm-)Arbeitsplätze, zur Druckerinfrastruktur (Einzel- und 
Netzwerkdrucker), zu Speichermedien, Internet-Zugängen und zum Umfang der in 
einer Zeiteinheit, etwa im Monat, zu bearbeitenden Daten unter Berücksichtigung 
von Stammdaten (z.B. Kundenadressen und -konten, Artikel und Materialien, 
Kostenstellen) und Bewegungsdaten (z.B. Kundenaufträge pro Woche/Monat, 
Warenzugänge, Rechnungen, etc.). Änderungen im Stammdaten-Management 
(etwa zur Harmonisierung) können sich auf alle Geschäftsprozesse auswirken; sie 
müssen deshalb als Change Requests durchgeführt werden. 

Zu erfassen sind schließlich die vorhandenen IT- Komponenten und Software- 36 
Anwendungen, 60 insbesondere, soweit diese weiter verwendet werden sollen. 

Die Ist-Aufnahme wird mittels Interviews, Ausfüllen von Fragebögen oder Beo- 37 
bachtung durchgeführt. Die jeweiligen Ergebnisse sollten zunächst nachprüfbar 
protokolliert und dann in einem Dokument zusammengefasst werden. 

Soll-Analyse 

Nach Erstellen der Ist-Analyse ist die Soll-Analyse durchzuführen. In ihr ist darzu- 38 
legen, welche Aufgaben sich künftig stellen werden, auf welche Weise diese zu erle- 
digen sind und welches Mengengerüst voraussichtlich benötigt werden wird. Hier- 
bei ist vorab zu prüfen, ob und gegebenenfalls welche Geschäftsprozesse optimiert 
werden (oder u.U. entfallen) können. Aufgetretene Probleme (z.B. zu ungenaue 
Formulare), Fehlerquellen bei Ergebnissen oder Engpässe (etwa bei gleichzeitiger 
Bearbeitung verschiedener Aufträge durch mehrere Mitarbeiter, Stoßbelastungen) 
sind zu berücksichtigen, ebenso Effizienzmängel (etwa mehrfaches Erfassen von 
Daten auf den verschiedenen Stufen eines Geschäftsprozesses). Ein Teil dieser Op- 
timierungen kann durch Umorganisation erfolgen, die vor Erstellung des Lasten- 
/Pflichtenhefts durchzuführen ist (damit dieses nicht von einer inzwischen überhol- 
ten Basis ausgeht) . Ein anderer T eil wird durch zu beschaffende neue Applikationen 
zu leisten sein. Deren Anforderungen müssen komplett in der Leistungsvorgabe für 
den Anbieter erfasst sein. 

Zu prüfen sind benötigte Schnittstellen zu vorhandenen Anwendungen, 61 ebenso 39 
solche zu Partnerfirmen. Weiter ist der vorhandene Datenbestand zu prüfen, da 
sich sein Umfang auf den Ressourcenverbrauch und die anzuschaffende IT- 
Infrastruktur auswirken kann. 62 Auch kann die Übernahme größerer Altdatenbe- 
stände einen nicht unerheblichen Aufwand erfordern, etwa wenn gesondert Kon- 
vertierungsprogramme erstellt werden müssen. Die Altdatenübernahme ist grund- 



60 Streitz, IT-Projekte retten, 28. 

61 Streitz, IT-Projekte retten, 30. 

62 Streitz, IT-Projekte retten, 128. 
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sätzlich Obliegenheit des Auftraggebers, wenn sie nicht als Leistung des Auftrag- 
nehmers ergänzend vereinbart wurde. 

40 Zu prüfen ist, ob Standardsoftware am Markt für den Einsatzzweck angeboten 
wird und inwieweit sie die Geschäftsprozesse abdeckt. Geraten wird, u.U. lieber 
Einschränkungen im Grad der Abdeckung der Funktionen in Kauf zu nehmen als 
teure (und fehlerträchtige) Individualentwicklungen zu beauftragen. 63 

41 Die Ergebnisse aus dieser Soll-Analyse sind in einem Fachkonzept 64 darzulegen. 
Hieraus werden dann primär die fachlichen V orgaben und Anforderungen in einem 
Lastenheft (im Sinne der Praxis)/Pflichtenheft (im Sinne der Rechtsprechung) de- 
tailliert aufgeschlüsselt. 65 Dieses wird teilweise auch als „fachliche Feinspezifikation“ 
bezeichnet 66 oder in § I BVB-Planung als „fachliches Feinkonzept“ (auf dem das - 
vom Anbieter zu erstellende - technische Feinkonzept des § 1 Nr. 1 S. 1 BVB-Erstel- 
lung aufsetzt 67 ). Mangels abweichender Vereinbarung ist es der Auftraggeber, der 
das Lastenheft (bzw. fachliche Pflichtenheft) erstellen muss, sofern (wie bei kom- 
plexeren IT-Projekten meist der Fall) ein solches benötigt wird. Das Spezifizieren 
der zur Erfüllung der fachlichen Aufgaben erforderlichen IT (im IT-Pfhchtenheft) 
hegt hingegen grundsätzlich in der Verantwortlichkeit des beauftragten Anbieters. 68 
Das Lastenheft muss Zielvorgaben klar definieren und vollständig sein. Unklarhei- 
ten und Lücken wirken zum Nachteil des Auftraggebers. Zwar muss der Auftrag- 
nehmer, auch wenn er keine Pflicht zur Erstellung des Lastenhefts übernimmt, 
trotzdem auf für ihn erkennbare Widersprüche oder Lücken im Pflichtenheft des 
Auftraggebers hinweisen - aber eben nur in diesem Bereich des Erkennbaren. 



63 Streitz, IT-Projekte retten, 29. 

64 Die BVB-Planung unterscheiden in § 1 Nr. 1 a)-c) weiter zwischen Grobkonzept und 
fachlichem Feinkonzept. 

65 Streitz, IT-Projekte retten, 23. Nach VDI 2519 beinhaltet das Lastenheft die quantifi- 
zierbare und prüfbare, vom Auftraggeber als Ausschreibungs- oder Vertragsgrundlage 
zu erstellende Beschreibung aller Anforderungen aus Anwendersicht einschließlich aller 
Randbedingungen, also das „Was und Wofür“, das Pflichtenheft hingegen die Beschrei- 
bung der Realisierung des Lastenhefts. 

66 Schneider/v. Westphalen, Software-Erstellungsverträge, C Rdn. 57ff. 

67 Die Besonderen Vertragsbedingungen unterscheiden zwischen der Planung, die vorbe- 
reitende Arbeiten für ein Grobkonzept, die Erarbeitung des Grobkonzepts und die Er- 
arbeitung des fachlichen Feinkonzepts umfasst (§ 1 Nr. 1 BVB-Planung), und der ei- 
gentlichen Erstellung, die mit dem Erstellen des DV-technischen Feinkonzepts beginnt 
(§ 1 Nr. 1 a BGB-Erstellung) und außerdem das Programmieren sowie das Herbeifüh- 
ren der Funktionsfähigkeit auf bestimmten DV-Anlagen und -Geräten umfasst (§ 1 
Nr. 1 b BVB-Erstellung) sowie das Erstellen der Dokumentation (§ 1 Nr. 1 c BVB- 
Erstellung). 

68 So etwa das OLG Köln CR 1994, 212; Müller-Hengstenberg, Risikoteilung in DV- 
Projekten, CR 1995, 198, 202. 
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Hat es der Auftraggeber versäumt, bestimmte Leistungsmerkmale rechtzeitig zu 42 
spezifizieren, kann er sich nicht auf das Fehlen der entsprechenden Programm- 
funktionen als Mangel berufen. 69 Das wird jedenfalls dann gelten, wenn das Fehlen 
der näheren Spezifikation dieser Funktionen für den Anbieter nicht erkennbar 
sein musste und er deshalb keine Hinweispflicht hatte. Der Anbieter schuldet 
dann die Leistung ohne die nichtspezifizierten Merkmale. Ist diese Leistung für 
den Auftraggeber in dieser Form nicht brauchbar, kann er dennoch keine Mängel- 
rechte geltend machen und der Vertrag ist unverändert rechtswirksam; der Auf- 
traggeber trägt insoweit also das Spezifikationsrisiko. Allerdings kann der Auf- 
traggeber den Werkvertrag jederzeit kündigen, muss aber die vereinbarte 
Vergütung unter Anrechnung desjenigen bezahlen, was der Anbieter durch die 
Nichtweiterführung der Arbeiten an Aufwand erspart (§ 649 BGB). Meist wird der 
Anbieter seinen Kunden aber nicht derart ins Leere laufen lassen (und ihn damit 
definitiv verlieren), sondern, soweit machbar, eine Anpassung der Werkleistung 
(freilich gegen Mehrvergütung) anbieten. Diese Anpassung ist als Change Request 
zu behandeln 70 . Für den Auftraggeber hat sie den Vorteil, dass er mit dem Projekt 
nicht wieder von vorne beginnen muss. 

Der Beschreibungsumfang des Lasten-/Pflichtenhefts (im Sinne von fachlichem 43 
Feinkonzept) muss umfassen: 71 

• Ist-Zustand (Ausgangssituation), 

• Soll- Zustand (Zielbeschreibung), 

• Beschreibung der Schnittstellen z.B. zwischen Benutzer oder Nicht-EDV- 
Funktionseinheiten (z.B. elektronischen Steuerungen), jeweils mit Beschrei- 
bung von Bildschirmein- und -ausgaben, von Inhalten der Information und 
von Formaten, 

• Listenausgaben, 

• V erarbeitungsregeln, 

• Prüfregeln, 

• Mengengerüste, 

• Sicherung der Daten, 

• zeitlichen Rahmen, 

• Ergonomieanforderungen, 

• benötigte Erweiterungsmöglichkeiten. 



69 OLG München, Urt.v.15.2.1989 - 27 U 386/88, CR 1990, 646. 

70 S. Rdn. 152. 

71 Teilweise nach: Müller-Hengstenberg, BVB-Computersoftware, 177; Balzert, Lehrbuch 
der Software-Technik. Software-Entwicklung, 62. 
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44 Geraten wird außerdem, nicht nur zu spezifizieren, was gemacht werden soll, 
sondern auch, was nicht gemacht werden soll. 72 Dies kann für den Auftragnehmer 
wichtig sein, der solche ausgeklammerten Leistungsmerkmale als getrennt zu ver- 
gütende Sonderwünsche behandeln oder ihre Durchführung auf Grund des von 
ihm gewählten Software- Architekturansatzes ablehnen kann. 

45 Wird vom Auftraggeber das von ihm zu erbringende Lasten-/Pflichtenheft nicht 
erstellt, scheitert hieran (wie beim Unterbleiben der Spezifikation einzelner Funk- 
tionen) die Auftragsausführung durch den Auftragnehmer nicht. Der Auftrag- 
nehmer ist vielmehr gehalten, eine Leistung zu erbringen, die nach den allgemei- 
nen Grundsätzen dem Stand der Technik bei mittlerem Ausführungsstandard 
entspricht. 73 Was unter „mittlerem Ausführungsstandard“ zu verstehen ist, er- 
scheint im IT-Bereich allerdings nur unzureichend geklärt (was angesichts der 
raschen technischen Entwicklung auch nicht überraschen kann). Dies begründet 
für den Auftraggeber das mitunter nicht unbeträchtliche Risiko, weniger Anbieter- 
leistung zu bekommen als eigentlich benötigt, ohne dass aber eine Pflichtverlet- 
zung des Anbieters vorläge. Diesem Risiko kann der Auftraggeber nur durch sorg- 
fältige und umfassende Lasten-/Pflichtenhefterstellung Vorbeugen oder durch 
Beauftragung des Auftragnehmers auch mit der Lasten-/Pflichtenhefterstellung. 
Zur Ausfüllung bestehender Lücken ist auf die gewöhnliche Verwendung der 
Software zurückzugreifen, 74 die freilich bei (lückenhaft definierter) individueller 
Anpassung ebenfalls schwer feststellbar ist. Gesetzliche Vorgaben an die Anwen- 
dung muss die Software vereinbarungsunabhängig erfüllen. 75 

46 Aber auch der Auftragnehmer muss ein Interesse an der (kundenseitigen) Erstel- 
lung der fachlichen Vorgaben haben. Behauptet der Auftraggeber nämlich, der 
Vertrag sei (teilweise) nichterfüllt, muss der Auftragnehmer die Erfüllung be- 
haupten und beweisen (der Auftraggeber hingegen, welche Leistung geschuldet 
gewesen ist). Hierzu muss er aber darlegen können, dass er den mittleren Ausfüh- 
rungsstandard eingehalten hat, 76 den er hierfür freilich auf eigenes Risiko zunächst 
herausfinden muss (und der nicht mit der üblichen Praxis des Auftragnehmers 
identisch zu sein braucht). Außerdem hilft die Bezugnahme auf einen darlegbaren 
mittleren Ausführungsstandard wenig, wenn mangels Pflichtenheft nicht einmal 
die Aufgabenstellung näher beschreibbar ist. 



72 Hindel/Hörmannl Müllerl Schmied, Basiswissen Software-Projektmanagement, 29. 

73 BGH, Urt.v.24.9.1991 - X ZR 85/90, CR 1992, 543 - „Vergessenes Pflichtenheft“. 

74 Schneider/v.Westphalen/Redeker, Software-Erstellungsverträge, D Rdn. 285. 

75 Schneider/v.Westphalen/Redeker, Software-Erstellungsverträge, D Rdn. 286; Koch, 
Handbuch Software- und Datenbank- Recht, § 5 Rdn. 13. 

76 Schneider/v. Westphalen, Software-Erstellungsverträge, C Rdn. 37. 
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Soweit Instanzgerichte teilweise zur Auffassung gelangten, dass mangels Vorliegen 47 
eines Pflichtenhefts (bzw. eigentlich Lastenhefts) des Kunden der Anbieter keine 
Leistung schulde oder dass er, umgekehrt, selbst die Anforderungen seines Kun- 
den eruieren müsse, ist diese Auffassung durch die erwähnte BGH-Rechts- 
prechung insoweit überholt, als überhaupt eine Leistung definierbar ist. Außer- 
dem hat der Anbieter den Auftraggeber auf das Fehlen des fachlichen 
Pflichtenhefts (bzw. der Problemanalyse) hinzuweisen, 77 soweit seine Erstellung 
vorgesehen und erforderlich war. Unterbleibt ein solcher Hinweis, kann ein Bera- 
tungsverschulden des Anbieters vorliegen. Weiter wird eine Verpflichtung des 
Anbieters zu bejahen sein, seinen Kunden vorab davon zu informieren, wenn 
(und dass) er ohne Lastenheft des Kunden mit der Leistungserbringung beginnt 
und spezifische Anforderungen also nicht wird berücksichtigen können. 

Bei der Erstellung des Lasten-/Pflichtenhefts durch den Auftraggeber hat der Auf- 48 
tragnehmer im erforderlichen Umfang mitzuwirken, so etwa bei der Formulie- 
rung der Aufgabenstellung und eines Organisationsvorschlags, 78 ebenso durch 
Hinweise auf für den Auftragnehmer erkennbare Unklarheiten und (scheinbar) 
unberücksichtigt gebliebene Anforderungen. 79 Zumindest muss der Auftragneh- 
mer die Ausführungen des Auftraggebers auf deren Plausibilität hin überprüfen. 80 
Näher konkretisiert wird diese Prüfpflicht etwa in § 3 Nr. 1 Abs. 2 BVB-Erstellung. 

Ist hiernach die Leistungsbeschreibung oder eine Forderung des Auftraggebers 
fehlerhaft, unvollständig, nicht eindeutig oder objektiv nicht ausführbar, muss der 
Auftragnehmer dies und die erkennbaren Folgen hieraus dem Auftraggeber un- 
verzüglich schriftlich mitteilen. Eine Verletzung der auftragnehmerseitigen Mit- 
wirkungspflicht 81 kann Schadensersatzansprüche des Auftraggebers begründen. 82 
Auf der Grundlage dieser fachlichen Feinspezifikation kann der Anbieter dann für 
seine Leistungserbringung eine IT-Feinspezifikation erstellen, auf der seine Leis- 
tungserbringung aufbaut. 

Eine feingerasterte Leistungsspezifikation verliert allerdings schnell an Kontroll- 49 
tauglichkeit, wenn während der Projektdurchführung Änderungen und/oder Er- 
gänzungen erfolgen, die nicht in der anfänglichen Spezifikation erfasst sind. Auch 
ist hier nicht sichergestellt, dass solche „Changes“ keine nachteiligen Auswirkun- 
gen auf bereits erbrachte Leistungsteile haben, die dann zeitaufwendig wieder 



77 OLG München, Urt.v. 25.9.1986 - 24 U 775/85, NJW-RR 1988, 436 - Musikalienkata- 
log. 

78 OLG Köln, Urt.v.6.3.1998 - 19 U 228/97, CR 1998, 459. 

79 OLG Köln, CR 1 998, 459. 

80 Schneider/v. Westphalen, Software-Erstellungsverträge, C Rdn. 172, 178. 

81 Anders als bei der Mitwirkung des Auftraggebers handelt es sich nicht nur um eine 
Obliegenheit, sondern um eine Vertragspflicht, die zumindest Nebenpflichtstatus hat. 

82 Schneider/v. Westphalen, Software-Erstellungsverträge, C Rdn. 180. 
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beseitigt oder umgangen werden müssen. 83 Unverzichtbare Änderungen sind also 
einerseits in der Spezifikation ergänzend nachzutragen und andererseits vom 
Anbieter vor Ausführung auf ihre Vereinbarkeit mit den bereits bestehenden 
Leistungsteilen zu untersuchen. Das Fortbestehen dieser Vereinbarkeit muss ab- 
soluten Vorrang haben. 

50 Die endgültige Fassung des Pflichtenhefts sollte (schon aus Beweisgründen) als 
solche bezeichnet und von beiden Seiten unterzeichnet 84 werden. Die Vertragspar- 
teien müssen beachten, dass das Pflichtenheft die Basis für die spätere Entwick- 
lung ist und hierauf aufbaut; deshalb ist die offizielle Freigabe einer endgültigen 
Version wesentlich. 85 

(2) Erstellung des Lasten-/Pflichtenheftes durch den Anbieter 

51 Verfügt der Auftraggeber nicht über ausreichend Fachkunde, qualifiziertes Perso- 
nal und/oder Zeit, kann es für ihn sinnvoll sein, den Anbieter zunächst mit der 
Erstellung des fachlichen Lasten-/Pflichtenheftes zu beauftragen, dessen Feststel- 
lungen dann bei der Erstellung des IT- Pflichtenheftes und der Leistungserbrin- 
gung abzuarbeiten sind. Zwei Dinge sind hier aber zu beachten: 

52 Der Auftraggeber hat meist besseres fachbezogenes Branchenwissen als der IT- 
Anbieter. Die Geschäftsprozesse sollten deshalb von ihm beschrieben werden, 
während der Anbieter eher eine Plausibilitätsprüfung auf Unvollständigkeiten und 
Widersprüche durchführen sollte. Eine Beauftragung einer IT -Anbieterfirma mit 
dieser fachlichen Analyse sollte eher eine Ausnahme darstellen und kann etwa in 
Betracht kommen, wenn der Anbieter zunächst Business-Reengineering-Maß- 
nahmen der fachlichen Abläufe durchzuführen oder aus anderen, vergleichbaren 
Projekten bereits branchenspezifische Erfahrungen gesammelt hat. 

53 Der Auftraggeber sollte hier zudem immer im Auge behalten, dass derartiges Tä- 
tigwerden des Anbieters im fachlichen Bereich des Auftraggebers zu einem Ab- 
fluss wertvollen Know-hows an Konkurrenten führen kann, die später ähnliche 
Lösungen vom Anbieter implementiert erhalten (und damit eventuell Wettbe- 
werbsrückstände gegenüber dem Auftraggeber aufholen können). Außerdem kann 
der Auftragnehmer geneigt sein, die Erstellung des fachlichen Pflichtenhefts dazu 
zu nutzen, seine eigenen späteren Leistungspflichten möglichst vage bzw. wenig 
kontrollfähig zu beschreiben. 86 



83 Ähnlich Zähmt, Projektmanagement von IT -Verträgen, 71. 

84 Klotz/Dorn, Vertragsmanagement in der Informationsverarbeitung, 85. 

85 HindellHörmannl Müllerl Schmied, Basiswissen Software-Projektmanagement, 41. 

86 Heussen, Richtige Vertragsgestaltung und Ablaufkontrolle bei EDV-Projekten, 54. 
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Der Auftraggeber muss bei der anbieterseitigen Erstellung des fachlichen Pflich- 54 
tenhefts zumindest insoweit mitwirken (Obliegenheit, sofern nicht Pflicht verein- 
bart), als dies für eine fehlerfreie Problemanalyse bzw. Leistungsbeschreibung 
erforderlich ist 87 oder für eine Richtigkeits- oder Machbarkeitskontrolle. Seine 
Verantwortlichkeit bleibt es, eventuell benötigte behördliche Genehmigungen 
einzuholen 88 , etwa nach Exportkontrollrecht. 

Die Auswahl und/oder Erstellung von IT-Komponenten sollte andererseits primär 55 
durch den hier in der Regel kompetenteren Anbieter unter der Fragestellung er- 
folgen, welche IT-Lösung die fachlichen Anforderungen am besten erfüllt. Dies 
muss nicht zwingend in jedem Fall die allerneueste Technologie oder Version 
einer Software sein, die vielleicht noch unausgereift und fehleranfällig ist. 

Die beauftragte Erstellung des Lasten-/Pflichtenhefts folgt grundsätzlich, da auf 56 
einen Leistungserfolg bezogen (nämlich das projekttaugliche Lasten-/Pflichten- 
heft). Werkvertragsrecht . 89 

Wurde das Pflichtenheft vom Anbieter nicht (rechtzeitig) erstellt und fehlen des- 57 
halb wichtige Spezifikationen, wurde eine Pflicht des Anbieters zur nachträglichen 
Erstellung (oder Ergänzung) des Pflichtenhefts bejaht. 90 Liier besteht freilich gele- 
gentlich das Risiko, dass der Anbieter das Pflichtenheft auf den bereits erbrachten 
Status seiner Leistungen hin formuliert und offene Punkte nicht erwähnt oder nur 
als Sonderwünsche. Werden aber tatsächlich wesentliche Details oder deren Ände- 
rung erst nachträglich festgelegt, ist es in der Praxis zuweilen eher fraglich, ob das 
bereits erstellte Programm noch entsprechend umgearbeitet werden kann, ohne 
die zeitlichen und/oder finanziellen Begrenzungen zu überschreiten. Eine nach- 
trägliche Pflichtenhefterstellung nach Abnahme wurde außerdem als nicht mehr 
notwendig angesehen. 91 

Entsprechende Abgrenzungsprobleme kann und muss die Geschäftsleitung des 58 
Auftraggebers dadurch vermeiden, dass die Pflichtenhefterstellung im Projektver- 
trag ausdrücklich geregelt wird, und ebenso, dass der Anbieter mit der Ausführung 
von Erstellungs- oder Anpassungsarbeiten erst beginnen darf, wenn das komplette 
Pflichtenheft vorliegt und vom Auftraggeber geprüft und gebilligt wurde. 



87 BGH BB 1989, Beilage 5, 2 = CR 1989, 102 - Restaurantkassen. 

88 Heussen/Hoh, Controlling von EDV-Projekten, 37. 

89 Müller-Hengstenberg , Der Vertrag als Mittel des Risikomanagements, CR 2005, 385, 
390; Intveenl Lohmann, CR 2003, 640, 644. 

90 Schneider/v.'Westphalen/Redeker, Software-Erstellungsverträge, D Rdn. 184. 

91 BGH BB 1993, Beilage Nr. 3; Schneider/v.Westphalen/Recfeker, Software-Erstellungs- 
verträge, D Rdn. 186. 
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Checkliste zur Erstellung des fachlichen Pflichtenhefts: 

Zielvorgaben 92 

• Vollständigkeit: Sind alle relevanten Punkte geklärt und notwendigen Informa- 
tionen eingeholt? 

• Korrektheit: Sind die eingeholten Informationen von dritter Seite bestätigt und 
im Lastenheft zutreffend dokumentiert? 

• Aktualität: Sind die verwendeten Informationen, Dokumente und Technolo- 
gien aktuell? 

• Eindeutigkeit: Werden die Begriffe einheitlich und eindeutig verwendet? Wer- 
den sie von den Vertragspartnern in derselben Weise verstanden? 

• Detaillierungsgrad: Sind die Anforderungen ausreichend detailliert? 

(3) Erstellen des IT-bezogenen Pflichtenhefts und (technischen) Feinkonzepts 

59 Auf der Basis des im Lastenheft (nach dem Sprachgebrauch der Rechtsprechung: 
im Pflichtenheft) abgebildeten Fachkonzepts wird (meist durch den Anbieter) das 
technische Systemkonzept erstellt und in die Form eines auf die IT bezogenen 
Pflichtenhefts gefasst, 93 das festlegen soll, wie der Soll-Zustand erreicht wird. Na- 
heliegend ist, dass an dieser Schnittstelle zwischen fachlichem Lastenheft 
(/Pflichtenheft) und IT-bezogenem Pflichtenheft der Auftragnehmer tätig zu wer- 
den beginnt, da bei IT-bezogenen Festlegungen seine Kompetenz zum Tragen 
kommt. Die Erstellung des IT-Pflichtenhefts kann hierbei auch Gegenstand eines 
separaten Vertrages sein. Der Auftraggeber bleibt dann in seiner Entscheidung 
frei, ob er aus dem Projekt (noch in dieser Planungsphase) „aussteigt“ und in die- 
sem Fall nur die Aufwendungen für die Erstellung des IT-Pflichtenhefts bzw. der 
technischen Feinspezifikation vergütet. 94 Über die eigentliche Projektdurchfüh- 
rung ist dann ein weiterer Vertrag zu schließen. Vorteil für den Kunden ist, dass er 
in der anschließenden Ausschreibung und Auftragsvergabe frei ist. Nachteil dieser 
„Zwei-Verträge-Lösung“ ist freilich, dass grundsätzlich auch der Anbieter frei 
bleibt, ob bzw. zu welchen Konditionen er diesen Ausführungsvertrag abschließt. 
Ein Ausweg kann darin bestehen, dass gleich im ersten Vertrag über die Pflichten- 
hefterstellung ein Optionsrecht des Auftraggebers vereinbart wird, zu festgelegten 
Konditionen und Vergütungen (oder wenigstens einen Konditionenrahmen) spä- 
ter den Folgevertrag an den Auftragnehmer vergeben zu können. 



92 Nach Grevent/Krömker, Unklare Ziele gefährden Projekte, Computerwoche 2/2005, 30. 

93 Streitz, IT-Projekte retten, 23. Das „Pflichtenheft“ umfasst nach DIN 69901 die vom 
Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des Las- 
tenhefts. 

94 Schneider/v. Westphalen, Software-Erstellungsverträge, C Rdn. 269. 
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Die Auswahl eines geeigneten IT-Systems muss von der gewünschten, klar umris- 60 
senen und festgelegten Problemlösung her erfolgen. Hierbei gilt die Abfolge: 
Problemlösung — > Software — » Hardware. Die erarbeitete Problemlösung legt also 
die auszuwählende bzw. zu erstellende Software fest und die Software ihrerseits die 
Hardware. Ein falscher Weg wäre es, die individuellen betrieblichen Bedürfnisse 
an beim Anbieter gerade verfügbare Lösungen oder gar an beim Auftraggeber 
vorhandene IT-Systeme anzupassen. Von der Problemlösung her sind auch Pro- 
jektphasen (mit Milestones) und Kosten abzuleiten bzw. zu kalkulieren. 

Zuweilen erstellt auch der Auftraggeber das IT -bezogene Pflichtenheft. Dies ist 61 
nur anzuraten, wenn er auf eine erfahrene eigene IT- Abteilung zurückgreifen 
kann. Das Pflichtenheft kann (und muss) in diesen Fällen mit entsprechenden 
Risiken (für den Anbieter) unmittelbar die Grundlage für die Ausschreibung des 
Auftrags bilden. 

Schnittstellen zu anderen Anwendungen, Aufrüstbarkeit und Erweiterbarkeit 95 62 
sind bei der Zusammenstellung der abzuarbeitenden Vorgaben im Pflichtenheft 
zu berücksichtigen. Zu prüfen ist, ob Spezifikationen von Schnittstellen in Soft- 
ware fremder Anbieter vor Entwicklungsbeginn erst offengelegt werden müssen 
oder (etwa im Internet) bereits zugreifbar sind. Der beauftragte Anbieter ist zwar 
(wenn auch nur in engen Grenzen) urheberrechtlich berechtigt, Schnittstellen 
Dritter zur Herstellung von Kompatibilität zu analysieren (Dekompilation, § 69 e 
UrhG), doch kann der Aufwand für eine solche (schon aus Beweisgründen sorg- 
fältig zu dokumentierende) Analyse die Projektkosten deutlich erhöhen. Das gilt 
auch für die nachträgliche Analyse der Schnittstellen von auftraggebereigenen IT - 
Inseln (z.B. alten COBOL-Programmen), die oft nur unzureichend dokumentiert 
sind. Wenn irgend möglich, sollte Software mit Standardschnittstellen der Vorzug 
gegeben werden. 

Festzulegen sind bei objektorientierter Programmierung Klassen- und Objektde- 63 
finitionen. Das Pflichtenheft muss außerdem Betriebsbedingungen spezifizieren, 
ebenso Qualitätsanforderungen, Benutzeroberflächen, technische Produkt- und 
Entwicklungsumgebungen. 

Beginnt die Leistungspflicht des Auftragnehmers erst mit der Erstellung des IT- 64 
bezogenen Pflichtenhefts bzw. IT-technischen Feinkonzepts, setzt auch erst hier die 
erfolgsbezogene Erfüllungshaftung des Auftragnehmers als Werkunternehmer ein. 



95 



Streitz, IT-Projekte retten, 39, ausführlicher auf die unterschiedlichen Realisierungs- 
formen eingehend. 
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65 Das Pflichtenheft sollte zur verbindlichen Grundlage der Projektdurchführung 
gemacht werden. Es legt dann die Sollbeschaffenheit der vom Anbieter geschulde- 
ten Leistung fest. 96 Hierfür ist erforderlich, dass der Anbieter das Pflichtenheft 
dem Kunden übergibt und der Kunde dieses als Teilleistung abnimmt. Teilweise 
wird geraten, auftraggeberseits nur eine „Freigabe“ der Ergebnisse der Planungs- 
leistungen des Auftragnehmers zu erklären, die keine Abnahmewirkung (im Sinne 
von § 640 BGB) haben soll. 97 Folge wäre aber, dass der Auftraggeber einen fortbe- 
stehenden Erfüllungsanspruch hätte und die (Teil-) Vergütung für die Erbringung 
der Planungsleistungen (noch) nicht fällig würde (wenn nicht gesondert verein- 
bart). Hintergrund des Vorschlags einer bloßen Freigabe ohne Abnahmewirkung 
ist, dass der Auftraggeber bei Vorlegung des Pflichtenhefts meist noch nicht des- 
sen Eignung für die Software-Erstellung oder Anpassung prüfen kann. Hier wird 
aber zu differenzieren sein: Erstellt der Anbieter aus zusätzlicher Beauftragung das 
fachliche Pflichtenheft (Lastenheft), kann der Auftraggeber grundsätzlich meist 
durchaus prüfen, ob sämtliche Vorgaben richtig erfasst sind und die vorhandenen 
Geschäftsprozesse abgedeckt werden. Die Frage nach der Umsetzung in die IT 
stellt sich nicht, da diese erst im IT-bezogenen Pflichtenheft darzulegen ist. Für 
letzteres besteht aber wiederum in der Regel in dieser Phase kein Erfordernis zur 
Teilabnahme, da der Auftraggeber ohnehin erst an der erstellten Software prüfen 
kann, ob sie vertragsgemäß erstellt wurde, nicht aber schon aus einer Auflistung 
erst einzulösender IT-spezifischer Vorgaben. Das IT-bezogene Pflichtenheft sollte 
deshalb als integraler Teil der Erstellungs- oder Anpassungsleistung des Anbieters 
und nicht als getrennt abzunehmende Teilleistung behandelt werden. 98 

66 Änderungen des Inhalts des Pflichtenhefts dürfen nur in einem geregelten Ände- 
rungs(Change Request-) verfahren zulässig sein. 99 Das Change Management muss 
damit bereits bei der Erstellung des IT-Pfhchtenhefts (bzw. des beauftragten Las- 
tenhefts) einsetzen, nicht erst bei der Erstellung der Software selbst. Dies sollte im 
Projektvertrag unbedingt ausdrücklich geregelt sein. 

67 Die Einbindung des Projekts in das Qualitätssicherungssystem des Anbieters ist 
im Projektvertrag zu regeln und im Pflichtenheft darzulegen. Während die Ein- 
richtung des QS-Systems allgemein den Normen EN ISO 9000 folgt, müssen für 
die Software-Erstellung fachspezifische Qualitätsnormen für bestimmte Anwen- 
dungsbereiche gesondert bezeichnet und vereinbart werden. Die Bedeutung einer 
Qualitätsprüfung wird schnell deutlich, wenn man berücksichtigt, dass Fehlerkos- 



96 LG Trier, Urt.v.2.12.1992 - 5 0 1/92, CR 1995, 221 (für das fachbezogene Pfiichten- 
heft). 

97 Schneider/v. Westphalen, Software-Erstellungsverträge, C Rdn. 271. 

98 Ähnlich i.E. wohl Schneider /w.^N estphalen, Software-Erstellungsverträge, C Rdn. 301. 
Streitz, IT-Projekte retten, 4L 



99 
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ten etwa 80% bis 90% der gesamten Qualitätskosten ausmachen und die Kosten 
für das Auffinden (und Beseitigen) von Fehlern in den Phasen Entwurf, Realisie- 
rung, Systemtest und Betrieb im Verhältnis 1:8:15:60 stehen, also geradezu expo- 
nentiell ansteigend 00 

Aus dem IT- Pflichtenheft sind nun die Spezifikationen als Aufgabenstellungen 68 
für die Programmierung auszuarbeiten (IT-Feinkonzept). 101 Dies ist typische Auf- 
gabe des Anbieters. 

Die fachliche Lösung hat zeitlichen Vorrang vor der IT-technischen Lösung. Erst 69 
wenn die Klärung der benötigten Abläufe auf fachlicher Ebene (und eine eventuel- 
le Reorganisation) abgeschlossen ist, lässt sich der Einsatz von IT- Anwendungen 
oder die Änderung oder Erweiterung solcher Anwendungen näher prüfen und 
festlegen. Diese Trennung sollte unbedingt beachtet werden. Probleme der Pro- 
jektdurchführung lassen sich oft auf den Umstand zurückführen, dass der Auf- 
traggeber nach Vertragsschluss mit dem Anbieter und dem Beginn der Leistungs- 
erbringung durch diesen seine Geschäftsprozesse ändert oder erweitert, damit aber 
auch die Basis für die Erbringung der Anbieterleistungen. Manchmal übernimmt 
andererseits der Auftragnehmer aus früheren Aufträgen Ausarbeitungen von IT- 
Pflichtenheften und passt diese nur arbeitssparend leicht an. Dies birgt das Risiko, 
dass wesentliche Grundkonstellationen der geschuldeten Anwendungen unanaly- 
siert bleiben und die Anbieterleistung die Abnahmereife nicht erreicht. 

Der Auftraggeber muss beachten, dass sich vorhandene, also ungelöst gebliebene 70 
Probleme auf der fachlichen Ebene nicht durch IT-Einsatz lösen lassen, sondern 
nur verlagert werden. Läuft beispielsweise ein Geschäftsprozess zu langsam ab 
oder ist er nicht ausreichend transparent organisiert (dies wird dann zuweilen 
gern als „historisch gewachsen“ bezeichnet) oder ist er zu kostenträchtig, so hilft 
seine Abbildung in eine IT- Anwendung kein Stück weiter. Die auf IT-Einsatz 
umzustellenden oder für neue Applikationen anzupassenden Geschäftsprozesse 
müssen also zunächst einmal optimiert werden (sog. „Business Reengineering“), 
bevor mit einer IT- Systemeinführung oder -Umstellung begonnen werden kann. 
Erkennt nämlich der Kunde erst während der Umstellung, dass er bestimmte Pro- 
zesse durch Änderung ihrer Abläufe verbessern kann, führt dies nicht selten dazu, 
dass mit der Realisierung des IT-Projekts wieder von vorne begonnen werden 
muss oder jedenfalls wesentliche Leistungsteile anzupassen sind. Je weiter hierbei 
das IT-Projekt bereits fortgeschritten ist, desto kostenaufwendiger werden solche 
Änderungen der Projektvorgaben. 



100 Streitz, IT-Projekte retten, 43. 

101 Streitz, IT-Projekte retten, 23. 
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71 Anforderungen an eine Geschäftsprozesse steuernde IT sollten damit erst dann 
definiert werden, wenn die jeweiligen betrieblichen Abläufe in ihrer Form nach 
dem Reengineering feststehen. Dieser Status sollte dokumentiert werden. Er legt 
nämlich als „Ist-Status“ die Ausgangsbasis für die IT- Systemeinführung oder 
-änderung fest. Für den IT- Anbieter und sonstige beauftragte Dienstleister ergibt 
sich aus dem Ist-Status zugleich, welche DV- Abläufe bereits beim Kunden vor- 
handen sind und unterstützt oder mit umgestellt werden müssen. 

72 Im nächsten Schritt ist zu prüfen, welche Leistungssteigerungen durch den IT- 
Einsatz bzw. dessen Änderung erreicht werden sollen („Soll-Status“). Das IT- 
System kann z.B. derart weiterzuentwickeln sein, dass es die doppelte Anzahl von 
Kundenaufträgen oder zusätzliche Geschäftsprozesse bewältigt, oder Bestellungen 
über das Internet. Dieses Sollkonzept ist in der Weise darzustellen, dass dem An- 
bieter eine Abarbeitung Punkt für Punkt möglich ist. 

73 Aus solchen fachlichen Zielvorgaben sind also die Anforderungen an die betriebli- 
che IT abzuleiten. Keinesfalls sollte die Geschäftsleitung ohne Notwendigkeit den 
umgekehrten Weg wählen und ihre Geschäftsprozesse nur deshalb umgestalten, um 
sie an die angebotenen starren Abläufe in standardisierten IT- Anwendungen anzu- 
passen. Ziel muss im Gegenteil sein, die IT optimal an die vorgegebenen fachlichen 
Anforderungen des Unternehmens anzupassen, um dessen Wettbewerbsfähigkeit 
zu sichern und möglichst zu verbessern; dies wird teilweise „IT Alignment“ ge- 
nannt. 102 Dies bedeutet freilich nicht, den IT-Einsatz auf das Nötigste zu beschrän- 
ken und Projekte zur Neu- und Weiterentwicklung radikal zusammenzustreichen, 
da hierdurch nicht die langfristigen, strategischen Ziele des Unternehmens unter- 
stützt werden. 103 Allgemein müssen die technischen und organisatorischen Struktu- 
ren der IT die Unternehmensziele optimal unterstützen und die geplante, künftige 
Entwicklung des Unternehmens fördern („IT-Governance“). 104 Diese Anforderun- 
gen werden wie folgt aufgeschlüsselt; 105 

• Die Leistungserstellung der IT muss im Rahmen der IT-Security- Anforderung- 
en (Integrität, Vertraulichkeit, Verfügbarkeit) gewährleistet werden. 

• Die IT-Strukturen sollten offen und herstellerunabhängig sein. 

• Die IT-Strukturen müssen von den Kapazitäten her skalierbar sein; die Integra- 
tion von weiteren Partnern oder Tochterunternehmen muss unkompliziert 
möglich sein. 



102 Wintersteiger , IT-Strategien entwickeln und umsetzen, in: Tiemeyer (Hrg.), Handbuch 
IT-Management, 45. 

103 Buchtal Eull Schulte-Croonenberg, Strategisches IT-Management, 15. 

104 Seibold, IT-Risikomanagement, 164. 

105 Seibold, IT-Risikomanagement, 164. 
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• Eine einheitliche Datenbasis muss für alle Anwendungen gegeben sein (keine 
Redundanzen). 

• Ein effektives Schnittstellenmanagement hat zu erfolgen, d.h., Schnittstellen 
sind leicht einzubinden und die Verfügbarkeit der Schnittstellen garantiert. 

• Die Gesamtkosten (Total Cost of Ownership, TCO) für die einzelnen Anwen- 
dungen müssen möglichst gering sein. 

• Eine optimale Geschäftsprozessunterstützung über Unternehmensgrenzen hin- 
weg wird erwartet. 

Dieses Optimierungsziel sollte auf der Kundenseite stringent verfolgt werden, so 74 
etwa bei einer nüchternen Analyse, ob alte Systeme („EDV -Inseln“) wirklich noch 
weiterhin genutzt werden sollten, auch wenn sie manchem CIO vertraut geworden 
sind. Hier können nämlich Probleme auftreten, wenn etwa vorhandene Schnitt- 
stellen mit den neuen IT-Systemen nicht voll kompatibel sind und Daten deshalb 
zur Weiterverarbeitung in diese neu manuell eingegeben werden müssen oder 
wenn der Altanbieter die Unterstützung einer solchen Insel beendet. Systemein- 
führungen und -anpassungen sollten deshalb vom Kunden genutzt werden, um 
Hardware, Applikationen, Daten und Prozesse zu konsolidieren . 106 

Weiter muss das auftraggebende Unternehmen darauf sehen, dass die einzuset- 75 
zenden IT- Anwendungen für den gesamten geplanten Nutzungszeitraum qualifi- 
ziert durch Hardware -Wartungs- bzw. Software-Pflegeleistungen unterstützt 
werden müssen. Die zu beauftragenden Anbieter müssen für diesen gesamten 
Zeitraum ihre qualifizierte Leistungsbereitschaft im Systemvertrag garantieren 
(und notfalls durch Erfüllungsbürgschaften sichern). 

Bei größeren, über längere Zeiträume zu realisierenden Projekten lassen sich 76 
zwingend erforderliche Änderungen der Geschäftsprozesse während der Projekt- 
realisierung nicht immer ausschließen, etwa beim Wechsel von Produkten oder 
deren Aufgabe, beim Anwachsen der Kundenzahlen oder Änderungen in der 
Struktur der Lieferkette für die Produkte des Auftraggebers. Hier ist vom Auftrag- 
geber möglichst schon vorab näher einzugrenzen, welche zusätzlichen Leistungs- 
potentiale der betrieblichen IT erforderlich werden könnten, und mit dem Anbie- 
ter zu klären, ob die angebotenen IT-Systeme entsprechend erweitert werden 
können, ebenso, wie sich Produktänderungen in IT- Abläufen abbilden lassen. 
Natürlich kann die Erfassung solcher möglichen Änderungen nicht ähnlich voll- 
ständig erfolgen, wie sie für die vorhandenen Geschäftsprozesse möglich und 
notwendig ist. Aber es sollten zumindest Regelungen für typischerweise erwartba- 
re Änderungen getroffen werden. 



106 



Tiemeyer, IT- Architekturen - planen und managen, in: Tiemeyer (Hrg.), Handbuch IT- 
Management, 98ff. 
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77 Umgekehrt kann Zusatzaufwand (etwa durch Übernahme von Altdatenbeständen 
oder Schulungen) erforderlich werden, wenn während der Nutzungszeit technisch 
bedingte Wechsel entstehen, etwa auf Betriebssystemebene oder durch eine neue 
Version der eingesetzten Enterprise Resource Planning Software. Solche Ände- 
rungen der betrieblichen Einsatzbedingungen sind für Auftraggeber oft nur be- 
grenzt voraussehbar. Deshalb sollte mit dem Anbieter vertraglich vereinbart wer- 
den, in welchen derartigen Fällen und in welcher Form er seine Leistungen 
unverändert oder gegen welche Zusatzkosten erbringen wird. 

Checkliste zur Erstellung des IT-Pflichtenhefts 

Die Leistungsbeschreibung bzw. das IT-bezogene Pflichtenheft muss festlegen , 107 

• die vom Auftragnehmer zu erbringenden Leistungen, 

• die für Abnahmefähigkeit zu erfüllenden Leistungsmerkmale, 

• die Reihenfolge der Projektstufen mit Zeitplan. 

Diese Inhalte lassen sich in folgender Weise aufgliedern : 108 

• Feinspezifikation der Funktionen, 

• Kosten-/Nutzenschätzung, 

• Projektwertanalyse, 

• Festlegung der Teilprojekte, Arbeitspakete, Unterlieferanten, 

• Verfeinerung der Projektpläne, 

• endgültige Leistungsbeschreibung. 

2. Auftragsvergabe, Vertragsschluss, Aufwendungen vor Vertragsschluss 

78 Die Auftragsvergabe erfolgt in der Praxis grundsätzlich auf der Basis eines schrift- 
lichen IT-Projektvertrags. Mittels dieses Vertrags muss die Projektdurchführung 
gesteuert werden können. Der Auftraggeber wird bei praktisch jedem Projekt 
laufend folgende Schlüsselfragen zu prüfen haben : 109 

• Wird der Zeitrahmen eingehalten? 

• Erfolgt eine Budgetüberschreitung und gegebenenfalls in welcher Höhe? 

• Wie hoch ist der Fertigstellungsgrad zum jeweiligen Prüfzeitpunkt? 



107 Teilweise nach Schneider/v.Westphalen/WRzel, Software-Erstellungsverträge, F Rdn. 
139. 

108 Müller-Hengstenberg, Der Vertrag als Mittel des Risikomanagements, CR 2005, 385, 
389. 

109 Nach Streitz, IT-Projekte retten, 63. 
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Der IT-Projektvertrag muss geeignete Mittel - wie ein regelmäßiges Reporting, 79 
Teilabnahmen, Vergütung nach Milestones etc. - vorsehen, die eine zeitnahe regel- 
mäßige Kontrolle dieser Prüfpunkte erlauben. Diese Fortschrittsüberwachung kann 
etwa durch Terminlisten (oder Balkendiagramme) durchgeführt werden, die im 
Intranet geführt und durch taggenaue Eintragung des Projektleiters aktuell gehalten 
werden, den jeweiligen Soll- und Ist-Status aufzeigen (geplante und tatsächlich er- 
reichte Termine) und von der Geschäftsleitung online jederzeit abgefragt werden. 

Auf der Basis des fachlichen Lasten-/Pflichtenhefts erfolgt die Vergabe von Auf- 80 
trägen, u.U. zunächst getrennt für die Erstellung des IT-Pflichtenhefts. Die öffent- 
liche Hand muss die Leistungen ab Erreichen eines bestimmten Auftragsumfangs 
ausschreiben (s. Rdn. 343). 

Sind mehrere Leistungen durch verschiedene Anbieter zu erbringen, muss die 81 
Erbringung dieser Leistungen koordiniert werden. Der Auftraggeber kann hier 

• die Koordination selbst durchführen. Dies ist für ihn riskant, wenn die Auf- 
tragnehmer ihre Leistungen in zeitlicher Abfolge erbringen müssen, ein Anbie- 
ter mit seiner Leistung in Verzug gerät und alle weiteren Anbieter auf ihn war- 
ten müssen (der Auftraggeber hierdurch also den folgenden Anbietern 
gegenüber in Gläubigerverzug gerät, § 293 BGB). In der Verantwortung des 
Auftraggebers steht es, solchen Verzögerungen vorzubeugen. 

• einen Berater mit der Projektsteuerung beauftragen. Der Berater ist aber nur 
bei eigenen Versäumnissen haftbar zu machen, nicht bei nicht vorhersehbarem 
Leistungsverzug eines Anbieters. 

• einen IT- Anbieter als „Generalunternehmer“ beauftragen, der gegenüber dem 
Auftraggeber die Projekt durchführung und die Leistungen der zuarbeitenden 
Einzelanbieter (Subunternehmer als Erfüllungsgehilfen des Anbieters) als eige- 
ne Leistung schuldet und zu verantworten hat sowie eigene Leistungen erbringt 
(etwa das „Testing“) 110 . Dies ist für den Auftraggeber meist vorteilhaft. Da er 
nur einen Anspruchsgegner hat, kann die Generalunternehmerbeauftragung 
die Projektkosten aber deutlich erhöhen. 111 

Mangels abweichenden Vereinbarungen liegt die Verantwortlichkeit für die Leis- 
tungskoordination beim Auftraggeber. 112 



110 Erbringt der Unternehmer keine eigenen IT-Leistungen, spricht man (in Übernahme 
des Sprachgebrauchs im Baubereich) von einem „Generalübernehmer“ (OLG Köln, 
BauR 1976, 288ff). 

111 Subunternehmerkosten können bei R/3-Projekten zu einem Aufschlag von 20-25% der 
Projektkosten führen ( Ottomeier , Computerwoche, 45/2000, 17, 18). 

BGH, Urt.v. 22.3.1984 - VII ZR 50/82 NJW 1984, 1676. 



112 
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82 Grundsätzlich sollte der Auftraggeber danach streben, Systemkomponenten und 
Wartung/Pflege (Maintenance) und sonstige Leistungen möglichst aus einer 
Hand zu erhalten. Wird nämlich die Maintenance für einzelne Komponenten oder 
das gesamte IT-System von einem anderen Anbieter übernommen als dem Anbie- 
ter des Systems oder der Komponenten, kann dies dazu führen, dass die Qualität 
des IT-Systems deutlich sinkt. 

83 Grundsätzlich ist offen ausgelegten, in ihren Erweiterbarkeitsparametern klar 
definierten („nichtproprietären“) Systemen der Vorzug zu geben vor abgeschlos- 
senen, „proprietären“ Binnensystemen, die mit kaum vorab kalkulierbaren Folge- 
kosten aus der Herstellerbindung verbunden sind. Änderbarkeit von Software 
muss bereits bei deren Entwicklung als Merkmal implementiert sein. Änderbar- 
keit wird unterstützt durch modulare Struktur, abgeschlossene Module, aus- 
tauschbare Schnittstellen, strukturierte Dokumentation. 

84 Bei ausfallsensitiven Anwendungen empfiehlt sich der Einsatz fehlertoleranter 
Systeme. Bei aktiv redundanten Systemen arbeiten Ersatzrechner parallel dieselben 
Aufgaben wie das Primärsystem ab und können jederzeit die Aufgaben überneh- 
men („Constant Computing“). Vorteil: Die Anwendung läuft ohne Downtime 
weiter. Nachteil: Es entstehen entsprechend höhere Kosten. Bei passiv redundan- 
ten Systemen müssen die Ersatzsysteme erst aktiviert werden. Vorteil: Weniger 
Kosten fallen an. Nachteil: Es treten u.U. schadensverursachende Unterbrechun- 
gen auf, 113 bei Webpräsenzen meist nicht tragbar. 

85 Bei Nutzung von Software an mehreren Arbeitsplätzen sind die Anzahl der benö- 
tigten Lizenzen („Lizenz“ als Kurzbezeichnung verstanden im Sinne von urheber- 
rechtlichen Nutzungsrechten) und der jeweilige genaue Zeitpunkt des Beginns der 
Nutzungsberechtigung festzulegen (Lizenzmanagement). Zu klären und festzule- 
gen ist auch, auf welche (u.U. automatisierte) Weise zusätzliche Lizenzen in Be- 
nutzung genommen werden können und wie nicht mehr benötigte Lizenzrechte 
möglichst rasch terminiert werden können (etwa durch Kündigung). 114 Bei festge- 
stellter Mehrnutzung ohne Lizenzen (z.B. zusätzliche Arbeitsplätze) sollte umge- 
hend Kontakt mit dem Anbieter zwecks Nachlizenzierung aufgenommen werden. 
Sinnvoll ist das Führen und regelmäßige Aktualisieren eines Software-Inventars, 
in dem jedem Arbeitsplatz bzw. Mobilrechner ein Nutzungsrecht zugeordnet wird. 



113 S. etwa Computerwoche 5/2001, 37. 

114 Das gilt insbesondere auch bei Migrationsprojekten. Beim Wechsel z.B. zu Open- 
Source-Software stehen nicht selten nicht mehr benötigte Rechner mit Software noch 
recht lange auf den Fensterbänken herum (wie bei einem bekannten städtischen Um- 
stellungsprojekt), obwohl eine kostensparende Beendigung von Lizenz- und Software- 
Pflegeverträgen möglich wäre. 
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Für größere Software-Entwicklungsprojekte muss nicht nur die Anbieterpflicht 86 
zur Qualitätssicherung vereinbart werden, sondern etwa auch ein Zugangs-, Be- 
sichtigungs- und Kontrollrecht für die IT-Mitarbeiter bzw. den Projektleiter des 
Auftraggebers bezüglich der Räume des Auftragnehmers - ein Regelungspunkt, 
der erfahrungsgemäß nur schwer erfolgreich nachverhandelbar ist. Gleiches gilt 
für eine detaillierte Festlegung der in der Abnahme zu prüfenden Funktionen und 
Testdaten bzw. -Szenarien. 

Auch die Herausgabe bzw. Hinterlegung der - dokumentierten(l) - Sourcen 87 
(Quellformate) der Software müssen in der Verhandlungsphase vereinbart wer- 
den, da ein diesbezügliches Nachverhandeln oft teuer kommt bzw. ganz ausge- 
schlossen wird. Herausgabe bzw. Hinterlegung erledigen sich in den Fällen, in 
denen etwa eine Webseitenerstellung auf XML-Basis erfolgt, da der generierende 
Code jederzeit am Bildschirm im Browser eingesehen werden kann. Sie scheitert 
außerdem, soweit der Anbieter selbst Standardkomponenten Dritter einsetzt und 
hierfür über keine Sourcen verfügt. 

Bei größeren Projekten wird vor Auftragsvergabe oft eine Bonitätsprüfung des 88 
voraussichtlichen Auftragnehmers angezeigt sein. Dies gilt in jedem Fall bei län- 
gerfristigen Projekten zur Entwicklung von Individualsoftware, die der Anbieter 
zumindest teilweise, nämlich bis zum nächsten Milestone, vorfinanzieren muss. Es 
gilt aber auch für an betriebliche Anforderungen angepasste und sogar unverän- 
derte Standardsoftware, wenn diese während der vorgesehenen Nutzungsdauer 
durch Pflegemaßnahmen unterstützt werden soll. 

Der Abschluss des Projektvertrages setzt das Projekt in Gang und mit diesem die 89 
Haftung des Auftragnehmers für die Erfüllung der von ihm übernommenen Leis- 
tungspflichten. 

Jeder IT- Projektvertrag sollte die Zielsetzung des Projekts (in einer Präambel) 90 
näher bezeichnen (z.B. Optimierung von Produktionsabläufen). Alle Anforderun- 
gen sind aufzunehmen. Hieran muss auch der Anbieter interessiert sein. 

Im abzuschließenden Projektvertrag sollte erkennbar sein, welche Regelungen in- 91 
dividuell ausgehandelt wurden, also nicht der Kontrolle nach AGB-Recht unterlie- 
gen. Dies kann dadurch geschehen, dass vorbereitende Dokumente wie Ausschrei- 
bungsunterlagen, Leistungsbeschreibungen oder Protokolle aus Verhandlungen 
etc. dem Projektvertrag als Anlagen beigefügt werden. Individuell ausgehandelt 
werden meist der Leistungsumfang, die Leistungstermine, Projektmanagement, 
Qualitätskriterien und Qualitätssicherung, Abnahmeverfahren (Funktionsprüfung) 
und Vertragsstrafen. Unverändert bleiben hingegen meist Gewährleistungs- und 
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Haftungsregelungen, Fälligkeitsvereinbarungen, Nutzungsrechte und allgemeine 
Bestimmungen (etwa zum Gerichtsstand). 

92 Teilweise werden Rahmenverträge verwendet, in denen meist gleichbleibende 
Regelungen quasi „vor die Klammer gezogen“ werden. Solche Rahmenverträge 
stellen in der Regel AGB dar. Rahmenverträge müssen durch Einzelaufträge oder 
-Verträge ausgefüllt werden. Der Abschluss eines Rahmenvertrages allein begrün- 
det noch keine Leistungspflicht und verpflichtet als solcher auch nicht zur Ertei- 
lung bestimmter Einzelaufträge. Wird aber mit einem Vertrag unter dem Titel 
„Rahmenvertrag“ eine ständige Geschäftsbeziehung aufgebaut und in ihm die 
Grundlage hierfür sowie die Abnahme einer Mindestzahl von Waren geregelt, so 
liegt (entgegen der Vertragsbezeichnung) bereits eine verbindliche Bestellung vor. 
Normalerweise regeln Rahmenverträge nämlich nur bestimmte Einzelheiten erst 
künftig abzuschließender Verträge. 115 Aus einem Rahmenvertrag über freie Mitar- 
beit mit Vereinbarung einer Vergütung nach Stunden lässt sich noch nicht ablei- 
ten, ob Dienst- oder Werkvertragsrecht anwendbar sind. 116 

93 Kommt es zu keinem Vertragsschluss (weil etwa die zeit- oder kostenbezogenen 
Vorstellungen der Vertragsparteien nicht zur Übereinstimmung gebracht werden 
können), kann der Anbieter bis zu diesem Zeitpunkt getätigte Aufwendungen 
(z.B. für Produktpräsentationen oder eine vorläufige Analyse der fachlichen An- 
forderungen des Interessenten) nicht ersetzt verlangen, es sei denn, er durfte den 
Vertragsabschluss als sicher erwarten. 117 Beiden Vertragsparteien muss daran 
gelegen sein, kundenseitige Zusagen der Kostenübernahme oder aber das Nichter- 
reichen einer Einigung klar zu dokumentieren. 

3. Dokumentation der Anbieterleistung 

94 Erstellungsleistungen des Anbieters sind zu dokumentieren. Das gilt insbesondere 
für die Erstellung von Software. Eine Abnahmeprüfung sollte erst zu erfolgen 
haben, wenn die vereinbarte Dokumentation dem Auftraggeber übergeben wurde. 
Das ist in der Praxis keineswegs immer der Fall, da manche Anbieter das Schrei- 
ben der Dokumentation als lästige Arbeit gern auf das Projektende verschieben. 



115 OLG Köln, Urt.v.22.4.1994 - 19 U 145/93, CR 1994, 737 - Rahmenvertrag. 

116 LG Bonn, Urt.v.24.4.2001 - 10 O 62/00, CR 2001, 824. 

117 LG Stuttgart, Urt.v. 22.3.2002 - 8 0 420/99, JurPC Web-Dok.. 315/2002. Diese Ent- 
scheidung verdeutlicht besonders anschaulich, wie wichtig rechtzeitige Klärung des je- 
weiligen Verhandlungsstatus ist. Der Anbieter hatte nämlich, obwohl ein schriftlicher 
Vertragsentwurf kundenseits nicht unterzeichnet worden ist, bereits eine Software- 
Entwicklung bei Dritten in Auftrag gegeben und klagte deshalb Kosten hieraus von ü- 
ber 2 Millionen DM (!) ein. 
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Festzulegen ist auch, welche Dokumentation der Auftraggeber beanspruchen 95 
kann. Hier werden (zumindest für größere Anwendungen) vier Dokumentations- 
typen unterschieden: 118 In der Anwenderdokumentation werden Einstieg in die 
und Nutzung der Anwendung beschrieben; ohne diese Anwenderdokumentation 
ist meist keine Abnahmeprüfung möglich. In der Systemdokumentation werden 
technische Angaben zusammengefasst, die für Betrieb, Wartung und Pflege rele- 
vant sind. Die Betriebsdokumentation enthält für die Überwachung und Auf- 
rechterhaltung des Betriebs benötigte Informationen. In der Installationsdoku- 
mentation sollte der Auftragnehmer den Status nach Installation einschließlich 
erfolgter Parametrisierung festhalten. Oft wird ein am Bildschirm abrufbares Be- 
nutzerhandbuch installiert. 

Bei Individualentwicklungen oder Anpassungen vorhandener Software oder von 96 
zu erwerbender Standardsoftware ist eine Entwicklungsdokumentation jedenfalls 
dann (auch ohne besondere Vereinbarung) geschuldet, wenn der Auftraggeber 
(z.B. ein anderes Software-Haus) die Software selbst weiterentwickeln oder zu- 
mindest pflegen will. Besteht eine Verpflichtung des Anbieters zur Herausgabe des 
Quellformats (Sourcen), muss auch eine Quellcode-Dokumentation bzw. Be- 
schreibung mit übergeben werden. 119 Die Dokumentation ist ohne besondere 
Vereinbarung geschuldet; der Anbieter ist insoweit vorleistungspflichtig. 120 

Übergibt der Anbieter nicht die jeweils geschuldete Dokumentation (insbesondere 97 
die Anwenderdokumentation bzw. das Bedienerhandbuch), hat er eine Hauptleis- 
tungspflicht teilweise nichterfüllt 121 und der Kunde kann einen Teil der Vergütung 
zurückbehalten. Kann der Kunde eine Software ohne Anwenderdokumentation 
überhaupt nicht nutzen (z.B. nicht einmal laden), wird sogar vollständige Nichter- 
füllung anzunehmen sein und die Vergütung voll zurückbehalten werden können. 

Die jeweilige Dokumentation muss vom Auftragnehmer mangels abweichender 98 
Vereinbarung grundsätzlich erst bei Abschluss der Arbeiten an der Software gelie- 
fert werden. 122 

Werden selbständig nutzbare Module ausgeliefert (z.B. eine Buchhaltung), so 99 
muss auch die Dokumentation zu diesem Modul mitgeliefert werden (zumindest 
die Benutzerdokumentation). Außerdem darf die Dokumentation bei regelgerech- 
ter Qualitätssicherung nicht erst nachträglich erstellt werden, sondern ist parallel 
mit der Entwicklung/ Anpassung durchzuführen. 



118 Nach Streitz, IT-Projekte retten, 54. 

119 S. etwa Schneider/^. Westphalen, Software-Erstellungsverträge, C Rdn. 220. 

120 OLG Karlsruhe, Urt.v.16.8.2002 - 1 U 250/01, JurPC Web-Dok. 123/2003. 

121 BGH, Urt.v.4.1 1.1992 - VIII ZR 165/91, NJW 1993, 461 = CR 1993, 422. 
BGH, Urt.v. 20.2.2001 - X ZR 9/99, DB 2001, 1141 = CR 2001, 367. 



122 
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4. Phasen der Software-Erstellung 

100 In der - der Analysephase mit Erstellung von Ist- Analyse und Soll-Konzept folgen- 
den - Entwurfsphase sind der Systementwurf, dann die Programmspezifikation und 
schließlich der Programmentwurf zu erstellen. Es schließt sich die Realisierungspha- 
se mit Programmierung und Test an. Abgeschlossen wird das Projekt mit der Sys- 
temfreigabe und -einführung . 123 In diesem Ablauf sind eine Reihe von Punkten zu 
beachten. 

a) Standardlösungen, Parametrisierung, individuelle Anpassungen, Neuerstellung 

101 Genau sollte der Auftraggeber prüfen, ob und gegebenenfalls bis zu welchem Grad 
er mit einer angebotenen Standardlösung leben kann, die meist den Vorteil hat, 
bewährt, wenig fehlerhaft und kostengünstiger zu sein. Bezüglich solcher Stan- 
dardlösungen empfiehlt sich die Prüfung (auch) folgender Punkte : 124 

• Beschreibt ein „Blaupausen“-Dokument die Projektdurchführung mit Inhalt 
und Ablauf der Einführung und ist es auf die konkrete Situation anpassbar? 

• Wird eine Standardparametrisierung angeboten sowie ein „Testbed“ mit Test- 
daten und installierten Testprogrammen? In welcher Weise muss der Auftrag- 
geber an der Beibringung der Testdaten mitwirken? 

• W erden Standardparametrisierung und T estinstallation beim Kunden installiert? 

• Existiert eine in Umfang und Leistungsverhalten vergleichbare Referenzinstal- 
lation? 

102 Existiert keine fertig übernehmbare Standardlösung, sollte die Möglichkeit der 
Anpassung von Standardlösungen geprüft werden. Die Anpassung von Standard- 
software („Customizing“) an Kundenanforderungen kann grundsätzlich auf zwei 
Wegen erfolgen : 125 

Durch „Parametrisieren“ werden gewissermaßen Einstellungen an im Programm 
bereits vorgegebenen „Stellschrauben“ (Parametern) vorgenommen. Man stellt so 
etwa die Anzahl der lizenzierten Nutzer ein. Hier wurde ein Kaufvertrag mit Neben- 
leistungen angenommen . 126 Eingriffe in den Programmcode sind nicht erforderlich. 
Diese Einstellungsarbeiten können dennoch recht umfangreich sein, etwa bei Ein- 
führung unternehmenssteuernder Enterprise Resource Planning Software . 127 Auf 



123 Stahlknecht/ Hasenkamp, Einführung in die Wirtschaftsinformatik, 210. 

124 Nach Zähmt , Projektmanagement von IT-Verträgen, 124. 

125 S. näher Koch, ITRB, 2005, 140. 

126 LG Nürnberg-Fürth, CR 1992, 336, 338; Schneider/v.Westphalen/Redeker, Software- 
Erstellungsverträge, D Rdn. 109. 

127 Stahlknecht/ Hasenkamp, Einführung in die Wirtschaftsinformatik, 213. 
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diese Anpassungsleistung kann Werkvertragsrecht anzuwenden sein. 128 Diese 
Werkleistung kann sogar den Schwerpunkt des Vertrages bilden. 

Um die kostenbezogenen Vorteile von (parametrisierbarer) Standardsoftware zu 103 
retten, wird zuweilen versucht, die betrieblichen Abläufe an die Software anzupas- 
sen. 129 In einem gewissen Rahmen kann dies sinnvoll sein (besonders dann, wenn 
hierdurch „historisch gewachsene“ Redundanzen erkannt und beseitigt werden). 
Leistungskraft, Innovationsfähigkeit und damit Wettbewerbsfähigkeit des Unter- 
nehmens dürfen aber nicht beeinträchtigt werden. 

Programmierung kann (auch neben Parametrisierung) ergänzend erforderlich 104 
werden, etwa zur Erstellung von Programmen zur Konvertierung von Altdatenbe- 
ständen oder zwecks kundenspezifischer Ergänzung der angebotenen Standard- 
funktionalität (z.B. bei SAP R/3 mit ABAP4). Zu prüfen ist aber jeweils, ob derart 
erweiterte Programme voll „releasefähig“ bleiben, d.h. trotz individueller Ergän- 
zungen auch mit Folge-Releases lauffähig sind. 

Parametrisieren und/oder Programmierung können auch erforderlich werden, 
wenn bestimmte Standardsoftware in die Systemumgebung integriert 130 und mit 
anderen vorhandenen Anwendungen verknüpft werden soll. Dies kann etwa die 
Erstellung von Schnittstellen erforderlich machen. 

b) Portierung 

Eine typische Anbieterleistung ist die Portierung, also die Anpassung eines vorge- 105 
gebenen Programms an andere Betriebssystem-Plattformen. Zumindest für den 
Fall der Portierung einer vom Besteller zur Verfügung gestellten Software folgt 
diese Anpassung Werkvertragsrecht, 131 während bei Überlassung einer nach den 
Kundenanforderungen angepassten Software Werkliefervertrag angenommen 
wird. 132 



128 Schneider/v.Westphalen/Rede/cer, Software-Erstellungsverträge, D Rdn. 110. Nach 
Redeker soll hier freilich § 651 BGB jedenfalls analog anzuwenden sein. Die Anwen- 
dung von § 651 BGB wird aber in den Fällen nicht in Betracht kommen, in denen Stan- 
dardsoftware (nach Kaufrecht) geliefert und erst dann auf dem Kundensystem paramet- 
risiert wird (ähnlich Schneider/v.Westphalen/Redeker, Software-Erstellungsverträge, D 
Rdn. 113). 

129 Schneider/v.Westphalen/W/tze/, Software-Erstellungsverträge, F Rdn. 42. 

130 Schneider/v.Westphalen/WitzeZ, Software-Erstellungsverträge, F Rdn. 125. 

131 BGH, Urt.v. 9.10.2001 - X ZR 58/00, CR 2002, 93 = JurPC Web-Dok. 252/2001 (einen 
Werkliefervertrag i.S.v. § 651 BGB ablehnend) 

BGH, Urt.v. 9.10.2001 - X ZR 58/00, a.a.O.; BGH, Urt.v. 14.7.1993 - VIII ZR 147/92, 
NJW 1993, 2436f. 



132 
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c) Zusatzfunktionalität 

106 Das Problem fehlender oder überflüssiger Zusatzfunktionalität tritt auf beiden 
Seiten auf. Während Kunden nicht selten individuelle Sonderwünsche erfüllt se- 
hen wollen, bieten Software-Häuser (teil)standardisierte Software oft mit viel 
Funktionalität an, die der Kunde für seine Problemstellung nicht benötigt. In bei- 
den Fällen treten messbare Nachteile auf: Werden in Standardlösungen kunden- 
individuelle Anpassungen implementiert, führt dies aus Entwicklerperspektive zu 
einer Aufspaltung („forking“) verschiedener Entwicklungslinien, die jede Weiter- 
entwicklung von Standardprodukten wesentlich verteuert oder letztlich unmöglich 
macht. Der Aufwand zur Pflege der unterschiedlichen kundenspezifischen Re- 
leases kann nämlich exponentiell ansteigen. Andererseits kann der Kunde in der 
Optionenvielfalt umfassender Software-Pakete schnell die Orientierung verlieren; 
außerdem muss er die volle Funktionalität bezahlen, wenn er auch nur 20% nutzt. 
Der Kunde sollte also prüfen, ob und gegebenenfalls welche Funktionen bzw. 
Module als bloße „Nice-to-have‘s“ eigentlich verzichtbar sind. 

107 Nachträglich als Sonderwunsch verlangte Zusatzfunktionalität kann sehr teuer 
werden, allein schon aufgrund zusätzlich erforderlichen Testaufwands. Wenn 
irgend möglich, sollte der Kunde vor Vertragsabschluss prüfen, welche Zusatz- 
funktionen sich im Projektverlauf als erforderlich erweisen könnten, und hierfür 
gleich in den Verhandlungen bei Ausüben einer Option einen Preis vereinbaren. 
Hierdurch werden nicht nur die Projektkosten besser begrenzbar, sondern der 
Anbieter kann seinerseits rechtzeitig (und deshalb mit weniger Aufwand) Vorkeh- 
rungen zur Berücksichtigung dieser möglichen Zusatzfunktionen treffen. Aller- 
dings bleibt dieser Vorteil nur dann erhalten, wenn der Kunde konsequent darauf 
verzichtet, während des Projekts plötzlich doch noch andere, unabgestimmte Zu- 
satzfunktionen zu verlangen. 

d) Prototypen 

108 Häufig werden bei der Programmentwicklung Prototypen eingesetzt. Als „Proto- 
typ“ wird oft „ein - mit wesentlich geringerem Aufwand als das geplante Produkt - 
hergestelltes und zu erweiterndes, ausführbares Modell des geplanten Softwarepro- 
dukts“ definiert, „das nicht notwendigerweise alle Eigenschaften des Zielsystems 
besitzen muss, jedoch so geartet ist, dass vor der eigentlichen Systemimplementie- 
rung der Anwender die wesentlichen Systemeigenschaften erproben kann“ 133 . Die 
Definition ist unscharf; diese Unschärfe kann zu einem Leistungsrisiko führen. Wird 
nämlich dem Kunden ein Prototyp vorgeführt, so ist in seinem Einverständnis mit 
der jeweiligen Gestaltung dieses Prototyps noch nicht eine Abnahme bezüglich der 
kompletten Leistungsausgestaltung zu sehen. Andererseits muss sich der Kunde mit 
seiner Billigung zumindest an die vorgeführten Eigenschaften binden lassen, darf sie 



133 Brösslerl Siedersleben (Hrg.), Softwaretechnik, 84. 
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also nicht (jedenfalls bei gleichbleibender Vergütung) wieder völlig ändern. Außer- 
dem ist zu klären, ob der Prototyp als solcher für andere Aufträge (etwa von anderen 
Kunden in derselben Branche) wiederverwendet werden darf (auch wenn er spezifi- 
sches Branchenwissen inkorporiert enthält) oder wegzuwerfen ist. 

Problematisch kann die Entscheidung sein, auf der Basis des Prototyps die gesam- 109 
te Entwicklung durchzuführen; es kann methodisch bzw. software-technisch güns- 
tiger sein, das Programm nach Billigung entsprechend den Prototyp-Vorgaben zu 
entwickeln 134 . Meist bietet ein schnell („quick and dirty“) erstellter Prototyp (als 
„Wegwerf- oder Einzeltyp“ 135 ) keinen Ersatz für eine vertraglich abgesicherte An- 
forderungsdefinition, so insbesondere nicht hinsichtlich Antwortzeitverhalten 
oder Kopplung mit anderen Systemen 136 . Das seit den Achtzigerjahren 137 prakti- 
zierte Verfahren des Prototyping hat Vorteile, aber auch Nachteile. Der Kunde 
kann eher eigene Änderungswünsche einbringen, doch kann genau dies eine zeit- 
gerechte Projektbeendigung gefährden und den geplanten Entwicklungsaufwand 
deutlich erhöhen, wenn der Kunde immer neue Möglichkeiten entdeckt bzw. 
unentschieden ist. Auch besteht die Gefahr, dass Aspekte wie Wartbarkeit, Effi- 
zienz, Funktionserfüllung oder Sicherheit nicht ausreichend beachtet werden 138 . 

Geraten wird, Prototyping insbesondere etwa bei der Entwicklung von Benutzer- 1 10 
Oberflächen, Menüführungen und der zugrundeliegenden betriebswirtschaft- 
lichen Datenstrukturen einzusetzen und durch beide Vertragspartner gemeinsam 
festzulegen. 139 

e) Datenmigration 

Die Übernahme des Altdatenbestandes kann sich als Kostenfalle herausstellen 111 
(insbesondere, wenn kein aktuelles Mengengerüst vorliegt). Hier kann deshalb mit 
teilweise nicht unerheblichem Zusatzaufwand zu rechnen sein. 

Im Projektvertrag ist unbedingt genau zu regeln, wer für die Erfassung der Altda- 1 12 
tenbestände und deren Migration auf eine andere Plattform zuständig sein soll. 
Vorgeschlagen wird folgendes Ablaufschema für die Datenmigration: 140 



134 Brüssler! Siedersleben (Hrg.), a.a.O., 90. 

135 Koreimann , Grundlagen der Software-Entwicklung, 169. 

136 Suhr/Suhr, Software Engineering. Technik und Methodik, 108. 

137 S. bereits Meffert, CW v. 2.11.1984, 29 ff. 

138 Barkow, Prototyping kann zum Software-Chaos führen, Computerwoche v. 11.4.1986, 
28, 32. 

139 Heilmann/ Etzel! Richter, IT-Projektmanagement, 181. 

140 Nach Fischbach/Lachmann/Winnemuth , Altdatenmigation wird oft unterschätzt, Com- 
puterwoche 10/2002, 26. 
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• Migrationsplanung im Rahmen der Projektplanung, 

• Erhebung/Verifikation der Ausgangsdatenmodelle und der Datenqualität, 

• Planung der Datentransformation, 

• Transformation in das Zwischenformat, 

• Bereinigung, Abgleich, 

• Verifikation von Bereinigung/ Abgleich, 

• Transformation in die Zielformate, 

• Laden in die Testumgebung, 

• Laden in Produktivumgebung. 

f) Projektkosten 

113 Bereits bei Vertragsabschluss muss für die gesamte vorausgesehene Nutzungsdau- 
er kalkulierbar sein, wie hoch die Kosten für das IT-System bzw. aufgeteilt für 
Software und Hardware, aber auch für zusätzliche Beratungs-, Anpassungs- und 
vergleichbare Leistungen wie etwa Schulungen sind. Diese Kostenanalyse muss 
alle Teile der Systemleistungen erfassen, damit der Auftraggeber zu einer realitäts- 
nahen Kosten-Nutzen-Analyse gelangen kann. 

114 Soll eine Projekt(teil)durchführung unter Abrechnung nach Aufwand vereinbart 
werden, muss der Kunde vor Vertragsunterzeichnung klären, mit welchem Ge- 
samtaufwand voraussichtlich zu rechnen ist (Kostenvoranschlag). Der Anbieter 
sollte dann mit Erreichen der verschiedenen Projektstufen den Kostenvoranschlag 
fortschreiben und einen laufenden Ist/Soll- Vergleich durchführen. 141 Bei Berech- 
nung der Vergütung nach Aufwand sollte grundsätzlich Abrechnung auf der Basis 
von Stundenzetteln vereinbart werden, in denen die jeweils erbrachte Tätigkeit 
stichwortartig knapp (aber doch nachprüfbar) bezeichnet wird, ebenso der betei- 
ligte Mitarbeiter und die Stundenzahl. 

115 Teilvergütungen sollten je nach Projektfortschritt (etwa anknüpfend an Milesto- 
nes) fällig werden. Hierdurch werden nicht nur Zahlungen verschoben, sondern 
das Entstehen der Zahlungspflicht verschiebt sich oder entfällt, wenn nämlich der 
Milestone nicht nachweisbar erreicht ist. 142 

1 16 Pür viele Pälle zutreffend ist die Peststellung, dass der Auftraggeber bei der Pro- 
jektdurchführung wahrscheinlich mit erheblichen Mehrkosten zu rechnen habe; 
diese ergäben sich teils aus Reibungsverlusten, teils aus zusätzlichen, erst während 
der Projekt durchführung erkannten Projektanforderungen, da anfangs oft nicht 
mehr als die Grundlösung in Auftrag gegeben werde. 143 Preilich setzt das im Un- 



141 Zähmt, Projektmanagement von IT-Verträgen, 25. 

142 Buchtal Eul/Schulte-Croonenberg, Strategisches IT-Management, 60. 

143 Zähmt, Projektmanagement von IT-Verträgen, 121. 
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ternehmen übliche und immer strengere Kostencontrolling zunehmend engere 
Grenzen. Besser ist, zumindest die typischen bzw. voraussehbaren zusätzlichen 
Anforderungen („creeping requirements“ 144 ) bereits bei den Verhandlungen mit- 
zuplanen und günstigere Preise auszuhandeln, wenn diese Optionen gewählt wer- 
den. Außerdem müssen alle zusätzlichen Anforderungen im Change Management 
bearbeitet, d.h. genehmigt, priorisiert (oder verworfen) werden. 145 

g) Versteckter Aufwand des Auftraggebers 

Bei seiner Kostenkalkulation darf der Auftraggeber nicht seine eigenen projektbe- 117 
zogenen Aufwendungen übersehen. Insbesondere sollte er möglichst vor Auf- 
tragsvergabe den erforderlichen personellen und finanziellen Eigenaufwand etwa 
für die Umstellung vorhandener (manuell oder in Altsystemen geführter) Daten- 
bestände feststellen, ebenso den Zeitaufwand der Mitarbeiter (also Arbeitszeit) für 
die Mitwirkung bei Einführung, Erweiterung und Wechseln des Systems. 

h) Vergütung, Festpreis 

Vergütung der Leistung und Zahlungsweise sollten grundsätzlich ausdrücklich im 118 
Vertrag geregelt werden. Fehlt eine Vereinbarung bei Erstellung, ob überhaupt 
eine Vergütung geschuldet ist, gilt die Vergütung dann als geschuldet, wenn die 
Leistungserbringung nur gegen Vergütung zu erwarten ist (§ 632 Abs. 1 BGB). 

Fehlt eine Vereinbarung zur Vergütungshöhe, so gilt die „taxmäßige“ Vergütung 
als vereinbart (§ 632 Abs. 2 BGB). 

Da die Vergütung grundsätzlich erst mit Abnahme fällig wird (§ 641 Abs. 1 S. 1 119 
BGB), muss der Anbieter diese seine Vorleistung entsprechend vorfinanzieren. 
Jedoch kann er für in sich geschlossene Teile des Werkes Abschlagszahlungen für 
die erbrachten vertragsmäßigen Leistungen verlangen (§ 632 a BGB), also etwa für 
selbständig nutzbare Software-Module, 146 die allerdings im Wesentlichen mangel- 
frei sein müssen. 

Die Vereinbarung von Festpreisen verlagert das Risiko der Kosten für Mehrleis- 120 
tungen auf den Auftragnehmer. Elierdurch erhöht sich für den Kunden die Si- 
cherheit der Budgetplanung. Jedoch können Anbieter hier dazu tendieren, dieses 
Kostenrisiko durch höhere Preise für die Realisierung von Sonderwünschen des 
Kunden auszugleichen. Hier kann es sich empfehlen, zumindest für vorhersehbare 
Ergänzungs- und/oder Änderungswünsche bereits im Vertrag einen Kostenrah- 



144 Heilmannl Etzel/ Richter, IT-Projektmanagement, 73. 

145 Heilmannl Etzel/ Richter, IT-Projektmanagement, 73. 

146 Palandt/Sprau, Bürgerliches Gesetzbuch, § 632 a, Rdn. 5 (selbständig verwertbares 
Teilprogramm). 
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men zu vereinbaren. In jedem Fall muss der Anbieter rechtzeitig seine Kalkulati- 
onsgrundlagen im Hinblick auf die konkrete Aufgabenstellung überprüfen. 

121 Die Rechtsprechung hat allerdings begrenzt eine Öffnung von Festpreisvereinba- 
rungen zugelassen. Kommen zu den ursprünglich vereinbarten Leistungen erheb- 
liche, zunächst nicht vorgesehene Zusatzleistungen auf Veranlassen des Bestellers 
hinzu, begründet dies - unabhängig von einer entsprechenden ergänzenden Eini- 
gung - einen zusätzlichen Vergütungsanspruch. 147 Das Change-Request-Verfah- 
ren bietet hier eine Möglichkeit, eine Vereinbarung über die anfallenden Zusatz- 
kosten zu treffen. 

122 Anbietern wurde empfohlen, die Vereinbarung eines Festpreises an einen vorge- 
gebenen Termin für den Vertragsabschluss zu knüpfen und die Möglichkeit einer 
Erhöhung des Festpreises bei Verzögerung des Vertragsabschlusses vorzusehen. 148 
Die Mehrzahl der kundenverursachten Terminkonflikte tritt aber nicht durch 
Verzögerungen des Projektbeginns auf, sondern durch Verzögerungen notwendi- 
ger kundenseitiger Mitwirkungshandlungen während der Projektdurchführung, 
also nach Vertragsschluss. 

Festpreise werden meist nur für mehr oder weniger standardisierte Leistungen, etwa 
ein Customizing, angeboten, nicht aber für vom Aufwand her schwer kalkulierbare 
V orhaben individueller Software-Erstellung oder etwa Altdatenübernahmen. 

123 Den Umfang zum Festpreis angebotener Leistungen sollte der Anbieter tunlichst 
genau in der Leistungsspezifikation abgrenzen. Nur dann wird er vom Kunden 
gewünschte zusätzliche Leistungsmerkmale problemlos als außerhalb des Fest- 
preisrahmens gelegen abrechnen können. 

124 Die Zahlung von Teilen auch des Festpreises kann an das überprüfbare Erreichen 
von Projektstufen (Milestones) geknüpft werden (Zahlung nach Leistungsfort- 
schritt). 

i) Zeitplan für Projektaktivitäten 

125 Die einzelnen, vom Auftragnehmer zu erbringenden (Teil-)Leistungen sind in 
eine zeitliche Abfolge (Terminliste) zu bringen, ebenso die erforderlichen Mitwir- 
kungshandlungen des Auftraggebers. Ziel ist die Erstellung eines Projektzeitplans, 
aus dem für jede (Teil-)Leistung Beginn und Abschluss ablesbar sind und die Er- 
füllung dieser Vorgaben kontrolliert werden kann. Aus einem Projektzeitplan 
sollte also für jede Phase erkennbar sein, wann etwas zu tun ist, wer etwas zu tun 



147 BGH, Urt.v.8. 1.2002 - X ZR 6/00, JurPC Web-Dok. 98/2002. 

148 Zähmt, Projektmanagement von IT-Verträgen, 39. 
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hat und welche Kosten hierbei höchstens entstehen dürfen. 149 Außerdem liegt es 
nahe, zu Vergleichszwecken eine zusätzliche Spalte einzufügen, in der neben den 
geplanten Terminen die tatsächlich eingehaltenen bzw. verzögerten Termine ein- 
getragen werden. 

Termine zur Leistungserbringung durch den Anbieter sollten so ausgelegt sein, 126 
dass die fachgerechte Erbringung der vollständigen Leistung realistischerweise 
erwartet werden kann. Der Rahmen sollte also nicht zu eng gesetzt werden, aber 
auch nicht zu weit . 150 Im Terminplan sind auch die jeweils erforderlichen Mitwir- 
kungsleistungen zu berücksichtigen. 

Bei zeitsensitiven Änderungen (z.B. zusätzlicher Programmierung) müssen deren 127 
Auswirkungen auf den Zeitplan geprüft und gegebenenfalls Anpassungen einge- 
tragen werden. Dies muss im eingerichteten Change-Management- Verfahren 
erfolgen. 

Zu unflexibel erscheint meist das Festlegen bloßer Endtermine. Vielmehr sollte 128 
die Erbringung von Leistungsteilen mit Terminvorgaben („Milestones“) verbun- 
den werden. Die Fälligkeit von Teilvergütungen sollte nicht an die Termine als 
solche anknüpfen, sondern an das erfolgreiche Erreichen der Milestones . 151 Die 
Milestones sollten nicht zu weit auseinander liegen , 152 um eine zeitnahe Leistungs- 
kontrolle zu ermöglichen. Bei Erreichen eines Milestone sollte der Kunde berech- 
tigt sein, die Vertragsmäßigkeit der Teilleistungen auf der jeweiligen Stufe zu prü- 
fen. Auf diese Weise kann der Kunde den Projektfortschritt zeitnah überwachen. 

Zutreffend wird geraten, bei Terminfestlegungen Reservezeiten quasi als Puffer 129 
vorzusehen, da technische Schwierigkeiten, gescheiterte Teilabnahmen etc. zu 
Verzögerungen führen können . 153 Zu enge Terminvorgaben schaden letztlich dem 
Auftraggeber, wenn sie nicht erlauben, alle nötigen Entwicklungsschritte sauber zu 
durchlaufen, um dann kurz vor Projektende festzustellen, dass sich das Produkt 
und seine Komponenten nicht integrieren lassen oder sie eine unzureichende 
Qualität haben . 154 



149 Stahlknecht/ Hasenkamp, Einführung in die Wirtschaftsinformatik, 218. 

150 So vermerken Heilmann/ Etzel/ Richter, IT-Projektmanagement, 29, nicht ohne Grund, 
dass Parkinsons Gesetz, wonach jeder für eine Arbeit so viel Zeit verbraucht, wie ver- 
fügbar ist, auch auf IT-Projekte zutreffe. 

151 Zähmt, Projektmanagement von IT -Verträgen, 29. 

152 Streitz, IT-Projekte retten, 5. 

153 Streitz, IT-Projekte retten, 4, 50. 

154 Ebert, Systematisches Requirements Management, 90. 
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130 Der Auftraggeber sollte bei Vereinbarung fester Erstellungstermine oder fester 
Preise beachten, dass sich Mehraufwand bzw. Verzögerungen in Abstrichen bei 
der Qualität und der Dokumentation niederschlagen können 155 oder in erhöhten 
Kosten für Sonderwünsche, und diese Punkte genauer prüfen. 

131 Für ein Fixgeschäft ist die Einhaltung der Leistungszeit nach dem Parteiwillen 
derart wesentlich, dass mit der zeitgerechten Leistung das Geschäft stehen und 
fallen soll. 156 Notwendig ist also eine konkrete Abrede, an welchem Tag die Anlage 
installiert und an welchem Tag die Schulung durchgeführt werden soll. 157 In der 
einvernehmlichen Einarbeitung von Änderungswünschen kann bei einem Erstel- 
lungsprojekt eine stillschweigende Aufhebung des ursprünglich fest vereinbarten 
Fertigstellungstermines liegen. 158 IT-Projekte haben nur selten den Charakter von 
Fixgeschäften. 

j) Zutritt zu Systemen des Auftraggebers 

132 Entwicklungserfordernisse können verlangen, dass der Auftragnehmer Zutritt 
(und Zugriff) zu IT-Systemen des Auftraggebers erhält, um etwa Tests mit vor- 
handenen Anwendungen oder die geschuldete Installation durchzuführen. In 
dieser Zeit kann die Unterbrechung des produktiven Betriebs des IT-Systems 
erforderlich sein. Die Vertragsparteien sollten im IT-Projektvertrag die voraus- 
sichtliche bzw. maximale Dauer solcher Unterbrechungen und die Verfahren zur 
Kontrolle des Zutritts festlegen. 

k) Installation 

133 Im Projektvertrag zu regeln ist, welcher Vertragspartner die Installation durchzu- 
führen hat. Dies muss nicht immer der Anbieter, sondern kann auch der Kunde 
sein, wenn dieser über eine ausreichend erfahrene eigene IT- Abteilung verfügt. 
Dies darf aber eine zu einem an sich angemessenen Zeitpunkt vorgesehene Ab- 
nahme nicht verzögern. Der (späteste) Zeitpunkt für die Durchführung der In- 
stallation ist im Terminplan festzulegen. 

134 Auch Updates und neue Versionen von Software müssen installiert werden, sei es 
im Rahmen der Mängelhaftung oder als Leistung in Software-Pflegeverträgen. 
Hier ist zu klären und zu vereinbaren, wer diese Installation vornimmt, ob auto- 
matische Installationsroutinen eingesetzt werden und ob eine Funktionsprüfung 
nach Installation erfolgt (etwa zur Suche neuer Mängel, wenn im Patch gerügte 
Mängel beseitigt wurden). 



155 Streitz, IT-Projekte retten, 50. 

156 Palandt /Thomas, Bürgerliches Gesetzbuch, § 361 Rdn.2. 

157 OLG Düsseldorf, Urt.v. 20.1.1995 - 22 U 160/94, CR 1995, 268. 
BGH, Urt.v.24. 1 1 . 1 998 - X ZR 2 1 /96, NJW-RR 1 999, 3 1 97 
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I) Schulungen 

Anwendungsspezifisch sind Schulungsinhalte festzulegen. Vorkenntnisse der 135 
Teilnehmer sind angemessen zu berücksichtigen. Die Abnahme und bereits eine 
Einweisung setzen ausreichende Kenntnisse über die Applikation voraus. Ausrei- 
chend spezifizierte Regelungen sind deshalb möglichst schon im Projektvertrag zu 
treffen, um schulungsbedingte Verzögerungen zu vermeiden. Lernaufwand lässt 
sich nicht pauschal abschätzen, sondern muss meist im Einzelfall konkretisiert 
werden; so können erfahrene Schreibkräfte mehr Zeit zum Umgewöhnen auf neue 
Applikationen (z.B. Vista) benötigen als Neulinge zum ersten Lernen. 

5. Projektorganisation und -management 

Die Projektsteuerung liegt grundsätzlich im Verantwortlichkeitsbereich des Auf- 136 
traggebers, 159 soweit er nicht den/die Anbieter mit entsprechenden Steuerungsauf- 
gaben beauftragt. Der Auftraggeber muss insbesondere für die rechtzeitige Durch- 
führung von Mitwirkungshandlungen sorgen. Für die Steuerung der Software- 
Erstellung ist hingegen der Anbieter verantwortlich. 

Zunächst müssen für beide Vertragspartner die entscheidungsbefugten Mitarbei- 137 
ter als Verantwortliche benannt werden (die nicht immer mit dem CIO bzw. Pro- 
jektleiter identisch sein müssen). 

Soweit ein „Lenkungsausschuss“ einzurichten ist, sollte im Projektvertrag dessen 138 
Zusammensetzung festgelegt werden. Zu beachten ist, dass die Zusammensetzung 
nicht eine Vertragspartei in den Stand setzen darf, einseitig zu ihren Gunsten mit 
„ihrer“ Mehrheit Leistungspflichten oder gegebene Garantien einzuschränken 
bzw. den Auftragsumfang ohne Vergütungsanpassung auszuweiten. 

Das IT-Projekt sollte grundsätzlich in unterscheidbare und getrennt im Erreichen 139 
überprüfbare Phasen aufgeteilt werden. 160 Zu jedem Zeitpunkt müssen sich die 
Fragen beantworten lassen: 161 

• Wo stehen wir jetzt? 

• Was haben wir vor/hinter uns? 

• Was müssen wir ändern? 



159 Heussen/Hoh, Controlling von EDV-Projekten, 12. 

160 Müller-Hengstenberg , CR 2005, 385, 386, die Aufteilung in die Phasen Systemanalyse, 
Systemdesign (IT-Architektur), Systemumsetzung/Realisierung, Installation und War- 
tung/Pflege vorschlagend. 

161 Müller-Hengstenberg , CR 2005, 385, 387 nach Keller, Die Kunst, DV-Projekte zum 
Erfolg zu führen 1994, 83. 
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• Was kostet das? 

• Was sind die Auswirkungen auf die Unternehmensziele? 

140 Für Phasenaufteilungen kann auf unterschiedliche Vorgehensmodelle zurückge- 
griffen werden. Die Einhaltung eines bestimmten Vorgehensmodells durch den 
Anbieter bedarf besonderer Vereinbarung. Keine Phasenkonzepte existieren für 
Wartungs- und Pflegeleistungen. 162 

141 Die wesentlichen Projektrisiken sollten bereits bei den Vertragsverhandlungen 
angesprochen und Minimierungsmöglichkeiten geprüft werden. 163 Entsprechende 
Gesprächsprotokolle können später Grundlage für außergerichtliche Schlichtun- 
gen sein. 

142 Für jedes Projekt ist ein Projektstrukturplan zu erstellen, also (nach DIN 69901) 
eine vollständige hierarchische Anordnung aller Elemente des Projekts, vorzugs- 
weise in der Form eines Strukturdiagramms. Zwecks Darstellung im Plan sind die 
Abläufe in Arbeitsschritte aufzuteilen. Diese sollen weder zu klein sein (dann kann 
der Kontrollaufwand explodieren) noch zu groß (dann ist eine zeitnahe Fort- 
schrittskontrolle nicht mehr möglich). 164 

143 Der Projektfortschritt ist laufend zu erfassen. Hierzu sind in regelmäßigen Ab- 
ständen wichtige Projektstatusdaten wie Zeitdaten (Termine, geleistete Stunden/ 
Arbeitsaufwand), Fertigstellungsdaten und Kostendaten (Höhe und Art der ange- 
fallenen Kosten) festzustellen und mit den Zielvorgaben abzugleichen (Vergleich 
von Plan- und Istdaten). 165 Fortschrittsberichte kann der Kunde auch unter Bedin- 
gungen der Praxis erwarten, 166 allerdings wohl nur auf Projektebene, nicht hin- 
sichtlich aller einzelnen Aktivitäten (wenn nicht gesondert vereinbart). 

144 Die Ergebnisse der Projektfortschrittskontrolle sollten in einem Projektbericht an 
die Geschäftsleitung zusammengefasst werden, der folgende Punkte umfasst: 167 

• Stand der Projektarbeiten laut Plan (spezifiziert nach dem Status: fertiggestellt, 
d.h. erledigte Arbeitsteile, in Arbeit, in Unterbrechung, noch zu bearbeiten). 



162 Müller-Hengstenberg, Risikomanagement in DV-Projekten, CR 1999, 789, 791. 

163 Streitz, IT-Projekte retten, 155. 

164 Hindel/Hörmannl Müllerl Schmied, Basiswissen Software-Projektmanagement, 51. Die 
Autoren geben als Richtwert eine Zeitdauer von vier bis sechs Wochen an bzw. 160 
Stunden Aufwand. 

165 Tiemeyer, Projektmanagement, in: Tiemeyer (Hrg.), Handbuch IT-Management, 233, 
301. 

166 Hindel/Hörmannl Müller/ Schmied, Basiswissen Software-Projektmanagement, 81. 

167 Tiemeyer, Projektmanagement, in: Tiemeyer (Hrg.), Handbuch IT-Management, 233, 
307. 
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• Terminplan der Projektaktivitäten/-ergebnisse (Vergleich Ist- und Solltermine). 

• Kostenplan der Projektaktivitäten/-ergebnisse (Vergleich Soll- und Istkosten). 

• Übersicht über Kapazitätsbelastung. 

• Abweichungsanalysen (Beschreibung der zu erkennenden Auswirkungen von 
Abweichungen, mit Kommentaren und Vorschlägen für Steuerungsmaßnah- 
men). 

• Stand des Projektbudgets (Planansatz/bisher verbraucht/noch verfügbar). 

• Hinweise auf Probleme und Risiken (aktuelle Engpässe in der Projektar- 
beit/einer Änderung bedürfende Sachverhalte/ Risikobewertung). 

• Handlungsbedarf (notwendige Maßnahmen). 

• Projektbezogene Kennzahlen (Kosten/noch zu erwartende Restkosten, Termi- 
ne, Milestones, Kapazitäten). 

Die Projektdurchführung sollte begleitend dokumentiert werden . 168 Diese Pro- 145 
jektdokumentation muss den Projektablauf belegen . 169 Neben dem Vertrag und 
dem Lasten- bzw. Pflichtenheft sind durchgeführte Change Requests, Besprechun- 
gen und Abstimmungen zu dokumentieren, ebenso die Beendigung des Projekts. 

Der hierdurch bedingte organisatorische Mehraufwand wird meist allein schon 
durch die Verbesserung der Beweismöglichkeiten (beider Vertragsparteien) 
aufgewogen. Erstellte Protokolle aus Besprechungs- oder Abnahmeterminen 
sollten von beiden Seiten freigegeben werden . 170 

Teilweise wird das Führen eines „Projekttagebuchs“ empfohlen, das insbesondere 146 
Protokolle von Sitzungen des Lenkungsausschusses, von Abnahmeprüfungen, ge- 
troffenen Entscheidungen (etwa zu Leistungsänderungen) und einen Schlussbericht 
enthalten soll . 171 Beweiswert erhält dieses Projekttagebuch aber erst, wenn die Fest- 
stellungen in ihm von beiden Seiten akzeptiert und jeweils unterzeichnet werden. 

Das Projekt kann durch unzureichende Projektorganisation in die Gefahr des 147 
Scheiterns geraten. Auslöser können u.a. zu kurze Realisierungszeiten, sich än- 
dernde Leistungsvorgaben, fehlende oder unzureichende Protokollierung von 
Sitzungen oder unzureichend geregelte Änderungsverfahren sein, ebenso nicht 
umgesetzte Change Requests oder eine hohe Anzahl von diesen . 172 



168 Ausf. s. Streitz, IT-Projekte retten, 125. 

169 Schneider/v. Westphalen, Software-Erstellungsverträge, C Rdn. 207. 

170 Streitz, IT-Projekte retten, 128. 

171 Heussen , Richtige Vertragsgestaltung und Ablaufkontrolle bei EDV-Projekten, 120. 

172 Streitz, IT-Projekte retten, 5, 153, 157. 
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148 Die Geschäftsleitung des Auftraggebers sollte im Rahmen eines laufenden Pro- 
jektmonitorings folgende Punkte prüfen: 173 

• Sorgfältige Ausarbeitung der Leistungsspezifikationen. 

• Laufende Information über jeweiligen Projektstand. Vergleich der jeweiligen 
Leistungsergebnisse mit Fristen- und Aktivitätenplan und insbesondere mit 
klar definierten Milestones. 

• Genaue Festlegung von Leistungsänderungen und Begrenzung von Zusatzver- 
gütungen (Change-Management- Verfahren). 

• Wiederherstellbarkeit von Systemzuständen zu früheren Zeitpunkten (etwa bei 
dem vorherigen Milestone). 

• Sicherstellen, dass bei (Teil-)Abnahmen die Hauptleistungen vereinbarungs- 
gemäß erbracht wurden. 

Das Projektmanagement 174 ist mit verschiedenen, sich ergänzenden Pflichten 
(und Risiken bei deren Nichterfüllung) verbunden. Soweit einzelne Abschnitte des 
IT-Projekts auf den Auftragnehmer übertragen werden (z.B. Lastenhefterstellung, 
Erstellung und/oder Anpassung der Software), schuldet dieser die Projektsteue- 
rung als Erfolg im Sinne des Werkvertrags. 175 

Sind mehrere Auftragnehmer beteiligt, bleibt die Verantwortlichkeit für die Ko- 
ordination der Erbringung dieser Leistungen beim Auftraggeber (Koordination). 
Außerdem muss der Auftraggeber stets den Projektfortschritt kontrollieren. Dies 
gilt selbst dann, wenn ein Dritter mit dem Projektcontrolling beauftragt wird, 
denn auch hier muss der Auftraggeber zumindest die fachgerechte Durchführung 
dieses Projektcontrollings laufend prüfen. Verantwortlichkeit (in der Regel im 
Sinne einer Obliegenheit) des Auftraggebers bleibt außerdem, rechtzeitig alle er- 
forderlichen Beistellungs- und anderen Mitwirkungshandlungen zu erbringen 
(z.B. Gewähren des Zugangs zu IT-Systemen oder Altdatenübernahme, soweit 
nicht als Auftrag an den Anbieter vergeben). Die genaue Abgrenzung der jeweili- 
gen Verantwortlichkeiten ist etwa im Falle des Scheiterns des IT-Projekts von 
Bedeutung (und meist streitig), da eine Zuordnung der Ursache des Scheiterns 



173 Nach Streitz, IT-Projekte retten,158; Müller-Hengstenberg, CR 1995, 198, 190; Schnei- 
der/v.Westphalen/WüzeZ, Software-Erstellungsverträge, F Rdn. 183. 

174 „Projektmanagement“ wird in DIN 69901 definiert als die „Gesamtheit von Führungs- 
aufgaben, -Organisation, -techniken und -mittein für die Abwicklung eines Projekts“, 
„Projektmanagementsysteme“ in DIN 69905 als „organisatorisch abgrenzbares Ganzes, 
das durch das Zusammenwirken seiner Elemente in der Lage ist, Projekte vorzubereiten 
und abzuwickeln.“ 

175 Werkvertragsrecht ist auf Projektsteuerung anwendbar, wenn die auf einen Leistungser- 
folg bezogenen Aufgaben derart überwiegen, dass sie den Vertrag prägen (BGH, Urt.v. 
10.6.1999 - VII ZR 215/98, BB 1999, 1728 für Bauüberwachung durch beauftragten Ar- 
chitekten). 
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zum Bereich des Auftragnehmers dessen Verantwortlichkeit - und damit Scha- 
densersatzhaftung - begründen kann. 176 

Die wichtigsten Aufgaben des Projektmanagements sind: 177 

• Planung, Initialisierung, Steuerung und Kontrolle aller Aktivitäten, 

• Einordnung des Vorhabens in den unternehmerischen Gesamtzusammenhang, 

• Koordinierung aller Projektmitarbeiter, 

• Beherrschung der Komplexität, 

• Festsetzung der Einzelziele (und Termine für diese 178 ), 

• Koordinierung und Anpassung der Interessen der Projektbeteiligten, 

• Durchführung von Qualitätsmaßnahmen, 

• Kontrolle des Projektstatus, der Ergebnisse und der Abweichungen. 

Verschiedene Vorgehensmodelle sind für die Software-Entwicklung gebräuchlich, 149 
so etwa das Wasserfallmodell (Vorstudie, Analyse/Pflichtenheft, Design/Daten-/ 
Prozess- und Funktionsmodelle, Realisierung, Test und Abnahme) 179 , das Spiral- 
modell oder das V-Modell (der öffentlichen Hand in Deutschland). Mit dem 
V-Modell wird unterschieden zwischen Verifikation (Frage: „Haben wir das Pro- 
dukt richtig entwickelt?“) und Validierung (Frage: „Haben wir das richtige Pro- 
dukt entwickelt?“). 180 Die Verbindlichkeit eines bestimmten Vorgehensmodells für 
das Projekt bedarf, wie ausgeführt, der Vereinbarung im Vertrag. 

Das Eskalationsmanagement dient dazu, im Falle abweichender Beurteilungen 150 
etwa des Projektfortschritts einen außergerichtlichen Weg zur Streitbeilegung zu 
finden. 181 Hier kann zunächst die Schlichtungsentscheidung durch ein Eskalati- 
onsgremium aus Mitgliedern beider Seiten zu suchen sein. Als nächste Stufe kann 
die Beauftragung eines sachverständigen Schiedsgutachters in Betracht kommen, 
die Durchführung eines Mediationsverfahrens (mit beauftragten Mediatoren) 
oder eines Schlichtungsverfahrens einer Schlichtungsstelle. 



176 Grafv. Westphalen, CR 2000, 73, 79 für das Scheitern des Anbieters in seinem individu- 
alvertraglichen Pflichtenprogramm. 

177 Müller-Hengstenberg, Der Vertrag als Mittel des Risikomanagements, CR 2005, 385, 
387. 

178 der Verfasser. 

179 Seibold, IT-Risikomanagement, 172. 

180 Hindell Hörmann/ Müllerl Schmied, Basiswissen Software-Projektmanagement, 18. 

181 S. allgemein Schneider/v. Westphalen/ Witze/, Software-Erstellungsverträge, F Rdn. 
204 ff. 
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6. Change Management 

151 IT- Projekte erfahren im Laufe ihrer Durchführung nicht selten Änderungen und 
Ergänzungen. Deren Abarbeitung wird deshalb in Vertragsregelungen zum 
„Change Management“ erfasst. Regelmäßig fehlt in solchen Klauseln nun eine 
klare Unterscheidung 182 zwischen zwei Arten von Änderungen, nämlich Mängel- 
beseitigungen 183 , die der Anbieter kostenfrei erbringen muss, und echten Leis- 
tungsänderungen (oder -erweiterungen), deren Durchführung kostenpflichtig ist 
(Sonderwünsche). Ohne diese Unterscheidung kann es für Anbieter naheliegen, 
grundsätzlich für sämtliche Änderungen Kosten abzurechnen, wodurch Mängel 
gewissermaßen zusätzlichen Umsatz generieren würden. Das Interesse des Kun- 
den muss es deshalb sein klarzustellen, dass Mängelbeseitigungen keine Zusatz- 
kosten verursachen dürfen. 

152 Change Requests für Änderungen oder Ergänzungen der vereinbarten Leistungen 
werden grundsätzlich nur bei Vereinbarung als anbieterseits geschuldete Zusatz- 
anforderungen erbracht und sind meist mit Mehrkosten für den Anbieter verbun- 
den. Als Mehrvergütung kann der Anbieter diese zusätzlichen Kosten nur berech- 
nen, wenn dies (zumindest stillschweigend, § 632 Abs. 1 BGB) vereinbart war. Das 
Erfordernis kann sich (insbesondere bei längerdauernden Projekten) aus Ände- 
rungen der auftraggeberseitigen Anforderungen ergeben, ebenso aus Änderungen 
der Systemumgebung (insbesondere der Betriebssysteme) oder der gesetzlichen 
Anforderungen an die zu unterstützende Anwendung. 184 

153 Changes, die Mängelbeseitigungen erbrachter Leistungen beinhalten, müssen 
vom Anbieter ohne zusätzliche Vergütung durchgeführt werden. Auch die kun- 
denseitige Aufforderung zur Beseitigung eines gerügten Mangels stellt damit einen 
Change Request dar, dessen Bearbeitung für den Kunden aber kostenfrei erfolgen 
muss. 

154 Diese aufgezeigte Unterscheidung kann sich auf vielfältige Weise in der Praxis 
auswirken. Beispiel: Changes in der Software können deren Laufzeitverhalten in 
den mängelfreien Teilen verändern (meist: reduzieren). Ist dies aber vereinbart, 
können entsprechende weitere Anpassungen notwendig werden. Ist ein solcher 
Change nun sonderwunschbegründet, wird der Kunde i.d.R. auch die Mehrkosten 
aus solchen zusätzlichen Anpassungen tragen müssen. Ist der Change aber Folge 
der Beseitigung eines Leistungsmangels, muss der nachbesserungspflichtige An- 



182 Koch , Software- und Datenbankrecht, 341. 

183 Auch Mängelbeseitigungen stellen aus Informatiksicht „Changes“ dar ( Hansen/Neu- 
mann , Wirtschaftsinformatik I, 273). 

184 Schneider/v.Westphalen/Redeker, Software-Erstellungsverträge, D Rdn.189. 
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bieter auch die Kosten dieser zusätzlichen Anpassungen tragen, da diese ebenfalls 
eine Form der Mängelbeseitigung darstellen. 

Der Anbieter ist grundsätzlich nicht verpflichtet, eine vom Auftraggeber ge- 155 
wünschte, nicht mängelbedingte Änderung oder Ergänzung der vereinbarten 
Leistung durchzuführen. Ein Änderungsantrag des Kunden stellt insoweit nur 
eine Aufforderung des Anbieters dar, dem Kunden ein Angebot über die Durch- 
führung zu machen (invitatio ad offerendum). Der Anbieter wird ein solches An- 
gebot meist in den Fällen machen, in denen der Auftraggeber zur Zahlung einer 
angemessenen Zusatzvergütung bereit ist, hingegen einen Change ablehnen, wenn 
die Ausführung des gewünschten Change technisch nicht oder nur unter unver- 
hältnismäßigem Aufwand möglich wäre oder wenn die Auswirkungen des Change 
auf bereits erstellte Leistungsteile (gerade im Programmierungsbereich) nicht oder 
nur sehr schwer kontrollierbar sind. Sind diese Ausnahmen nicht gegeben, kann 
der Auftraggeber eine Anpassung des Vertrags in der Form der zusätzlichen Leis- 
tungserbringung jedenfalls dann verlangen, wenn die Vertragsparteien den Ver- 
trag mit diesen Änderungen geschlossen hätten, wären diese voraussehbar gewe- 
sen (§ 313 Abs. 1 BGB). 185 Ist diese Vertragsanpassung möglich, verlangt der 
Anbieter aber unangemessen hohe Zusatzvergütungen oder lehnt er die weiteren 
Leistungen generell ab, kann eine sofortige Kündigung aus wichtigem Grund in 
Betracht kommen 186 . Das hilft dem Kunden freilich wenig, wenn er das ganze 
Projekt dann mit einem anderen Anbieter neu beginnen müsste. 

Für jeden angeforderten Change sollte die Art des Change sowie die durch ihn 156 
ausgelösten Mehrkosten und möglichen Terminverschiebungen in einem Change - 
Request-Dokument festgehalten werden 187 , das beide Seiten unterzeichnen. Auch 
sollte für die Changes jeweils eine nachträgliche Spezifikation erfolgen bzw. die 
Spezifikation fortgeschrieben werden. 188 Diese Anforderungen werden teilweise in 
den ITIL- und ISO 20000-Spezifikationen zur Durchführung von Change Re- 
quests (s. unten Rdn. 688, 728) aufgenommen. 

Vor Durchführung eines Change sind die vorhersehbaren Auswirkungen des 157 
Change auf andere Teile der Anwendung zu prüfen, sei es in Design, Code, Test- 
plan oder Dokumentation. 189 Der Auftragnehmer muss außerdem prüfen, ob seine 
Software bei Durchführung des jeweiligen Change noch releasefähig ist, also in der 
an alle Kunden ausgelieferten Grundfunktionalität unverändert bleibt. 



185 Schneider/v.Westphalen/Redeker, Software-Erstellungsverträge, D Rdn.207; Koch , 
Handbuch Software- und Datenbank-Recht, § 3 Rdn. 21. 

186 Schneider/v.Westphalen/Redeker, Software-Erstellungsverträge, D Rdn.208. 

187 Schneider/v.Westphalen/Redefcer, Software-Erstellungsverträge, D Rdn.191. 

188 Zähmt, Projektmanagement von IT -Verträgen, 145. 

189 Hindell Hörmannl Müllerl Schmied, Basiswissen Software-Projektmanagement, 186. 
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158 Als Change sind auch Leistungsmerkmale zu erfassen, die der Kunde während des 
Projekts fallen lässt, da sich hierdurch ebenfalls die vertraglich geschuldete Leis- 
tung ändert . 190 Ob mit einem solchen partiellen Verzicht eine Vergütungsreduzie- 
rung verbunden werden kann, muss im Einzelfall geprüft und gesondert im Chan- 
ge-Request-Dokument vereinbart werden. 

159 Schließlich können Change Requests auch die Verschiebung von Terminen oder 
Änderungen von Mitwirkungshandlungen des Auftraggebers betreffen. Auch 
diese nicht unmittelbar leistungsbezogenen Changes in der Projektorganisation, 
nämlich die Termin- und Pflichtenanpassungen, müssen im geregelten Change- 
Request- Verfahren durchgeführt werden . 191 

160 Geregelt werden sollte, ob die Prüfung von Changes selbst schon eine Vergütung 
auslöst. Weiter ist zu regeln, ob bzw. ab welchem Umfang Changes bei vereinbar- 
tem Festpreis nur gegen Zusatzvergütung durchgeführt werden müssen. 

161 Die Ablehnung von gewünschten Changes sollte durch ausdrückliche Erklärung 
erfolgen . 192 Notwendig ist weiter eine Regelung, was gelten soll, wenn über einen 
Change Request keine Einigung erzielt werden kann . 193 

162 Jeder Change muss in seiner Durchführung dokumentiert werden. Die Durchfüh- 
rung von Changes sollte wie die Hauptleistung qualitätsgesichert erfolgen . 194 Das 
muss auch für Mängelbeseitigungen als Form von Changes gelten - in der Praxis 
keineswegs die Regel. 

163 Für die Reihenfolge der Bearbeitung mehrerer Change Requests sollte eine Priori- 
sierung erfolgen. Eine hohe Anzahl von Change Requests kann indizieren, dass 
die vorhergehende Leistungsphase nicht fertiggestellt und die Nachfolgephase auf 
ungesicherter Basis zu früh begonnen wurde . 195 Jedenfalls können erhebliche Zu- 
satzaufwendungen entstehen . 196 Eine wachsende Anzahl von Change Requests 
kann zu Projektverzögerungen führen. Auf derartige Auswirkungen hat der Auf- 
tragnehmer den Auftraggeber hinzuweisen. Der Auftragnehmer tut gut daran, 
entsprechende Fristverlängerungen gleich mit der Change- Durchführung schrift- 
lich zu vereinbaren. Eine AGB-Klausel, nach der sich der Kunde bei Durchfüh- 
rung von Änderungs- bzw. Ergänzungsarbeiten (also auch von Change Requests) 



190 S. näher Zähmt, Projektmanagement von IT-Verträgen, 82. 

191 Streitz, IT-Projekte retten, 133. 

192 Streitz, IT-Projekte retten, 135. 

193 Schneiderlv. Westphalen, Software-Erstellungsverträge, C Rdn. 189. 

194 Streitz, IT-Projekte retten, 135. 

195 Streitz, IT-Projekte retten, 6. 

196 Schneider/v.Westphalen/Redeker, Software-Erstellungsverträge, D Rdn.192. 
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nicht mehr auf früher vereinbarte Ausführungsfristen berufen kann, wurde AGB- 
rechtlich als zulässig angesehen. 197 

Anbietern muss daran gelegen sein zu klären, für welche zusätzlichen Leistungen 164 
Kosten berechnet werden dürfen. Dem BGH 198 zufolge muss nämlich der Anbieter 
bei Vertragsschluss in gewissem Umfang mit Änderungen oder Erweiterungen 
rechnen und entsprechende Möglichkeiten vorsehen. Nach dem Kammergericht 
Berlin 199 muss der Anbieter (allerdings bezogen auf einen Fall eines fehlenden 
Pflichtenhefts) mit gewissen Änderungen rechnen und sie in die Vergütung ein- 
preisen; das gilt auch bei Festpreisvereinbarung. 200 Er darf sie also nicht zusätzlich 
berechnen, was seinen Mehrvergütungsanspruch und Gewinn erheblich reduzie- 
ren kann. 

Die Vertragsparteien sollten deshalb projektspezifisch definieren, für welche Leis- 165 
tungen bzw. Leistungstypen in welchem Umfang Mehrvergütungen verlangt 
werden können. Hierzu müssen projektbezogen klare Kriterien vereinbart werden, 
was als Mängelbeseitigung gilt und was als Leistungsänderung, die jeweils aus- 
drücklich als solche vereinbart werden sollte. Grundsätzlich wird bei Beauftragung 
eines zusätzlichen Software-Moduls eine (marktübliche) zusätzliche Vergütung 
durch den Anbieter berechnet werden dürfen. 201 

In längerlaufenden Projekten muss auch bei möglichst präziser Leistungsspezifika- 166 
tion mit auf Lernprozessen begründeten neuen Unternehmensanforderungen und 
Weiterentwicklungen technischer Möglichkeiten gerechnet werden, 202 deren Be- 
rücksichtigung und Bearbeitung als Change Request nicht ausgeschlossen sein 
darf. Modulare Software-Architektur und die Aufteilung von IT-Projekten in 
Phasen unterstützen entsprechende Leistungsänderungen. Der Auftraggeber kann, 
wenn der Anbieter die Änderungsdurchführung ablehnt, die Anpassung über § 

313 Abs. 1 BGB für eine angemessene Zusatzvergütung verlangen. Grundsätzlich 
ist freilich zu beachten, dass die Anzahl der Änderungen nicht unbegrenzt steigen 
sollte (auch nicht bei Mehrvergütung). Jedes Projekt erreicht nämlich früher oder 
später den Punkt, an dem eine komplette Neudefinition des Projekts notwendig 
wird, 203 natürlich mit entsprechenden erheblichen Mehrkosten. 



197 BGH CR 1993, 424 - S-Projekt II. 

198 BGH, Urt.v. 24.6.1986 - X ZR 16/85, CR 1986, 799. 

199 KG Berlin, Urt.v. 1.6.1990 - 14 U 4238/86, CR 1990, 768, 770. 

200 Schneider/v.Westphalen/Redefcer, Software-Erstellungsverträge, D Rdn.202. 

201 Schneider/v.Westphalen/Redefcer, Software-Erstellungsverträge, D Rdn.203. 

202 Müller-Hengstenberg/Krcmar , CR 2002, 549, 553. 

203 Ebert, Systematisches Requirements Management, 170. 
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7. Mitwirkung des Auftraggebers 

167 Eine „ungeschützte Flanke“ der meisten Projekte ist die richtige und rechtzeitige 
Mitwirkung des auftraggebenden Kunden. Der Auftraggeber hat diese Mitwirkung 
als Obliegenheit 204 in Abstimmung mit dem Anbieter zu erfüllen. Hierfür ist in 
den meisten Fällen nicht ausreichend, dass der Auftraggeber nur mit allgemeinen 
Formulierungen in den Vertragsregelungen verpflichtet wird, in geeigneter Weise 
an der Projektdurchführung mitzuwirken. Der Auftraggeber kann hieraus nicht 
erkennen, welche konkreten Handlungen zu welchem Zeitpunkt durchzuführen 
sind. 

168 Zumindest die wichtigsten bzw. typischen Mitwirkungsobliegenheiten 205 müssen - 
möglichst schriftlich - und in kontrollfähiger Formulierung festgehalten werden 
(Programm 206 für die Kundenmitwirkung). Zumeist ist es Sache des Kunden, die 
für den Anbieter wesentlichen Installationsvoraussetzungen herzustellen, fach- 
kompetentes Personal zur Mitwirkung bei Anlieferung, Installation, Einweisung 
und Funktionsprüfung zu stellen und bezüglich des Eigentums des Anbieters (et- 
wa an dessen Rechnern) Verkehrssicherungspflichten bzw. vertragliche Schutz- 
pflichten zu übernehmen. 207 

169 Voraussetzung einer Abnahmeprüfung ist eine Kundenmitwirkung durch folgen- 
de Handlungen: 208 

• Festlegen des Mengengerüsts, Mengenprofile, Antwortzeiten, 

• Aufbereiten der Testdaten für alle maßgeblichen Anwendungsfälle, 

• Dokumentation der gefundenen Mängel. 

170 Fehlt es an solchen Festlegungen für bestimmte Pflichten des Kunden, wird der 
Anbieter mit der Behauptung und dem Beweis auf Schwierigkeiten stoßen, der 
Kunde habe eine bestimmte Mitwirkungsobliegenheit/-pflicht verletzt. In den 
meisten Projekten lassen sich freilich nicht sämtliche Mitwirkungshandlungen 
vollständig erfassen und im Vertrag formulieren. 209 Aber zumindest die typischen 



204 Schneider/v.Westphalen/Redeker, Software-Erstellungsverträge, D Rdn.267 m.w.N.; 
Müller-Hengstenberg/Krcmar , CR 2002, 549, 554. 

205 Streitz, IT-Projekte retten, 137 spricht von „Beistellungen“. 

206 Da es sich meist um Mitwirkungsobliegenheiten handelt, wird in diesem Zusammen- 
hang nicht von einem „Pflichten“programm gesprochen. 

207 Koch , Computer- Vertragsrecht, Rdn. 669. 

208 Müller-Hengstenberg/Wild, Abnahme von Computerprogrammen, CR 1991, 327, 331. 

209 Deswegen werden Anbieter auch nicht ohne Weiteres eine Klausel akzeptieren, derzu- 
folge für den Kunden nur die ausdrücklich im Vertrag (oder in einem Anhang hierzu) 
benannten Pflichten gelten sollen und darüber hinaus keine Pflichten bestehen (so v. 
Holleben , Computerwoche 4/2004, 30, 31). 
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und für das Erreichen des Projekterfolgs entscheidenden Mitwirkungshandlungen 
sind aufzulisten. Hierzu gehören das Bereithalten und Zugänglichmachen der IT- 
Systeme und das Gewähren von Zugang zu den Räumlichkeiten, in denen die 
Systeme stehen, die Auflistung und ggf. Konvertierung von Altdaten, die Teil- 
nahme an Schulungen und das Durchführen von Funktionsprüfungen, das Erstel- 
len von Testdaten. 

Der Auftraggeber muss sich darauf einrichten, dass das Erbringen der erforderli- 171 
chen Mitwirkungshandlungen personal-, zeit- und kostenintensiv ist. Nach Schät- 
zungen kann der entsprechende zusätzliche Aufwand des Auftraggebers zwischen 
30% und 50% des beauftragten Aufwands betragen. 210 Genauer kalkulieren kann 
der Auftraggeber diesen Aufwand nur, wenn er vom Anbieter eine Auflistung der 
wichtigsten Mitwirkungshandlungen und ihrer voraussichtlichen Dauer erhält 
oder sie jedenfalls mit dem Anbieter erarbeitet. 

Die Erfüllung von Obliegenheiten des Kunden kann der Anbieter nicht klageweise 172 
erzwingen. Für den Anbieter genügt es als Schutz„filter“ in den meisten Fällen, bei 
nicht erfolgender Mitwirkung durch den Kunden selbst nicht in Leistungsverzug 
zu geraten 211 , eine Entschädigung verlangen zu können (§ 642 Abs. 1 BGB) und 
nur für grobe Fahrlässigkeit (und natürlich Vorsatz) zu haften (§ 300 Abs. 1 BGB). 

Auch soll er bei Nichtliefern einfacher Programmiervorgaben durch den Kunden 
berechtigt sein, sich auf die Grundprogrammierung zu beschränken und Vergü- 
tung so zu verlangen, als hätte er vollständig programmiert. 212 

Ein zwingendes Erfordernis, diese Obliegenheiten im Vertrag zu klagbaren Mit- 173 
wirkungspflichten aufzuwerten, 213 besteht damit zumeist nicht. 214 Dies kann an- 
ders sein, wenn der Anbieter Individualsoftware mit dem Auftraggeber als Pilot- 
kunden entwickelt, die später vom Anbieter als Standardsoftware vertrieben 
werden soll. 215 Hierbei ist aber nicht ausreichend, dass der Anbieter nur eine nicht 
dem Kunden kundgetane Vermarktungsabsicht hat. Der Vermarktungszweck 
sollte vielmehr zur Geschäftsgrundlage des Vertrags (i.S.v. § 313 BGB) gemacht 



210 Streitz, IT-Projekte retten, 56. 

211 BGH, Urt.v. 23.1.1996 - X ZR 105/93, CR 1996, 467; BGH, Urt.v.13.7.1988 - VIII ZR 
292/87, CR 1989, 102 mit Anm. Köhler, CR 1989, 105 = NJW-RR 1988, 1396; OLG 
Stuttgart, Urt.v.29.3.1994 - 6 U 203/93, CR 1994, 222 (Leitsatz) 

212 BGH, Urt.v.13.7.1988, a.a.O., 102, 104. 

213 Hierfür wohl Müller-Hengstenberg/Krcmar , CR 2002, 549, 555. 

214 A.A. wohl Schneider/v.Westphalen/WftzeZ, Software-Erstellungsverträge, F Rdn. 434. 
Müglich/Lapp, CR 2004, 801, sehen regelmäßig einklagbare Nebenpflichten als gegeben 
an. Wie hier regelmäßig Obliegenheiten annehmend Redeker, IT-Recht in der Praxis, 
Rdn. 432. 

215 Redeker , IT-Recht in der Praxis, Rdn. 434; Schneider/v.Westphalen/Redeker, Software- 
Erstellungsverträge, D Rdn. 271 ff. 
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worden sein, allerdings nur in einer Individualvereinbarung, wegen der Abwei- 
chung vom gesetzlichen Vertragsbild nicht in AGB . 216 Liegen nur allgemein gehal- 
tene Vertragsklauseln zur Kundenmitwirkung vor, wird deren Einstufung als Be- 
gründung einer Nebenpflicht in der Regel scheitern müssen. 

174 Projektkritische Mitwirkungshandlungen sollten bereits im Projektvertrag oder 
(zur Entlastung der Vertragsdokumente) in einem getrennten Dokument festge- 
legt werden, das ausdrücklich im Vertrag als Anhang erwähnt und zum Teil des 
Vertrags gemacht wird. Für den Anbieter wird eine unzureichende Beschreibung 
notwendiger Mitwirkungshandlungen spätestens dann misslich, wenn er das Un- 
terbleiben einer erforderlichen Mitwirkungshandlung des Kunden (z.B. Pflichten- 
hefterstellung, Altdatenübergabe zwecks Konvertierung) rügen will. Der Anbieter 
kann nicht eindeutig feststellen und in einem Prozess beweisen, zu welchem Zeit- 
punkt der Kunde welche Mitwirkungsleistung hätte erbringen müssen. Der Anbie- 
ter sollte also darauf achten, im Projektvertrag ein möglichst vollständiges und 
klar aufgeschlüsseltes „Obliegenheitsprogramm“ für den Kunden zu definieren. 
Aus ihm muss der Kunde erkennen können, wann für ihn welche Pflichten aktuell 
werden. Dies dient zugleich zur auch vertraglich vom Anbieter geschuldeten Auf- 
klärung und Beratung des Kunden, der z.B. Mitarbeiterschulungen und eine Ab- 
klärung mit dem Betriebsrat terminlich abstimmen muss. 

175 Die erstmalige Festlegung von Mitwirkungshandlungen erst in einem Kickoff- 
Meeting (nach Vertragsabschluss ) 217 hat den Nachteil, dass zwecks Einbeziehung 
dieser Kundenpflichten in den Vertrag eine Vertragsänderung erforderlich ist. 

176 Bestimmte Details der Durchführung der Mitwirkungshandlungen werden sich 
aber zuweilen erst nach Vertragsschluss festlegen lassen, so der Zeitraum, während 
dessen die Mitwirkung zu benennender Mitarbeiter des Auftraggebers mitwirken 
sollen . 218 Zu denken ist hier etwa an die Mitwirkung der kundeneigenen IT- 
Abteilung. Deren Verantwortlichkeit kann umfassen, kundeneigene Datenbestän- 
de zu erfassen und ggf. umzustellen. 

177 Der Anbieter ist gehalten, die jeweils erforderliche Mitwirkung rechtzeitig abzu- 
rufen (z.B. eine Information über Gegebenheiten im Auftraggeberbereich) und bei 
erkennbarer Unklarheit oder Unvollständigkeit beim Auftraggeber nachzufragen. 
Der Anbieter sollte hier sorgfältig den Umfang seiner bestehenden Aufklärungs-, 
Rücksichts- und Hinweispflichten prüfen. Sie sind nämlich Teil der Verhaltens- 
pflichten bzw. -Obliegenheiten, die beide Seiten, aber bei IT-Projekten in erhöhtem 



216 Redeker, a.a.O., Rdn. 434. 

217 Hierfür wohl Zähmt, Projektmanagement von IT-Verträgen, 64. 

218 Zähmt, Projektmanagement von IT-Verträgen, 69. 
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Maße gerade den Anbieter als Auftragnehmer treffen, da der Auftraggeber auf 
dessen Fachkunde vertraut. Auf das Fehlen von Mitwirkungshandlungen kann 
sich der Anbieter schließlich grundsätzlich nur berufen, wenn er den Auftraggeber 
zu ihrer Durchführung aufgefordert hat. 219 

Gewinnt der Anbieter den Eindruck, dass die Mitarbeiter des Kunden fachlich 178 
nicht ausreichend qualifiziert sind, wird dem Anbieter geraten, seine Frage schrift- 
lich abzufassen und Anleitungen zur Beantwortung zu geben. 220 Diese Situation 
kann freilich auch ein Indiz dafür sein, dass der Kunde seine fachliche Aufgaben- 
stellung nicht ausreichend analysiert hat bzw. unreflektiert an althergebrachten 
betrieblichen Traditionen festhält, die den Nutzen des Einsatzes betrieblicher IT 
reduzieren können. 

Wirkt der Auftraggeber in der erforderlichen Weise mit, scheitert dann aber das 179 
Projekt aus vom Auftragnehmer zu vertretenden Gründen, so gehören auch die 
Aufwendungen für die Durchführung der Mitwirkungsleistungen (z.B. die Altda- 
tenkonvertierung für das proprietäre Anbietersystem) zum zu ersetzenden Schaden. 

Vorgeschlagen wird, dass der Auftragnehmer den Auftraggeber regelmäßig über 180 
den Projektfortschritt unterrichtet. 221 Zwingend erforderlich sind solche Berichte, 
wenn der Auftragggeber zu einer bestimmten Mitwirkungshandlung oder einer 
(Teil-)Abnahme aufzufordern ist. 

Übersicht über wichtige typische kundenseitige Mitwirkungshandlungen: 222 181 

• Übermitteln aller benötigten Informationen an den Anbieter, etwa über (vor- 
handene) Systemumgebung, Schnittstellen, Unternehmensabläufe (Geschäfts- 
prozesse), fachliche Anforderungen. 

• Mitwirken bei Tests, Stellen von qualifiziertem Personal (insbesondere Projekt- 
leiter) und Testdaten. 

• Schaffen der erforderlichen Installationsvoraussetzungen und Internet-Anbin- 
dungen (etwa bei Outsourcing). 

• Beschaffen erforderlicher Systemkomponenten, soweit nicht vom Anbieter 
geschuldet. 

• Teilnahme ausreichend qualifizierter Mitarbeiter an Schulungen durch den 
Anbieter. 



219 Schneider/v.Westphalen/Redeker, Software-Erstellungsverträge, D Rdn. 431. 

220 Zähmt, Projektmanagement von IT -Verträgen, 72. 

221 Streitz, IT-Projekte retten, 63. 

222 Teilweise nach: Schmidt, in: Redeker (Hrg.), Handbuch der IT-Verträge, Abschnitt 1.5 
Rdn. 162. 
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• Vorbereiten und Durchführen der Abnahme. 

• Umgehende, vollständige Fehlermitteilungen auf Anbieterformularen. 

• Gewährleisten von Datenschutz und -Sicherheit sowie Know-how-Schutz. 

8. Abnahmeregelungen 
a) Grundsätze 

182 Eine erbrachte Werkleistung muss (mit der Folge der Fälligkeit der Vergütung 
und des Beginns des Laufes der Verjährungsfrist) vom Auftraggeber (Besteller) 
abgenommen werden, wenn sie im Wesentlichen vertragsgerecht erbracht wurde 
(§ 640 Abs. 1 S. 1 BGB). Bei Software-Projekten sind mittels der Abnahmeprüfung 
zwei Grundfragen zu klären: 

• Wurde das Produkt richtig entwickelt, also wie spezifiziert? (Verifizierung) 
Und: 

• Wurde das richtige Produkt entwickelt, also nicht an den Kundenanforderun- 
gen vorbei? (Validierung ). 223 Die Validierungskriterien müssen ausreichend 
konkret gefasst sein, 224 um eine Überprüfung zu gestatten. 

183 Beide Seiten, Auftraggeber ebenso wie Auftragnehmer, müssen ein Interesse daran 
haben, im Projektvertrag oder im Anhang hierzu eine Auflistung zu prüfender 
Leistungsmerkmale als verbindliche Abnahmekriterien zu definieren. Der Auf- 
traggeber kann mittels einer solchen Auflistung feststellen, welche Leistungs- 
merkmale (mindestens) nachprüfbar vorhanden sein müssen, damit seine Leis- 
tung als vertragsgemäß gelten darf, und ob diese Merkmale tatsächlich erfüllt sind. 
Der Auftragnehmer sichert durch diese Auflistung andererseits ab, dass das 
Erbrachtsein der Leistung konkret überprüfbar und beweisbar ist, und dass der 
Auftraggeber nicht Zahlungen zurückhalten kann, weil bestimmte Leistungs- 
merkmale (noch) nicht erfüllt seien, die z.B. tatsächlich nicht vereinbarte Sonder- 
wünsche darstellen. Die Prüfliste der Abnahmekriterien sollte aus dem fachlichen 
Pflichtenheft (Lastenheft) abgeleitet werden; deshalb sollte der Auftragnehmer 
entsprechend vertraglicher Vereinbarung mit seiner Leistungserbringung erst 
beginnen dürfen, wenn das Pflichtenheft vom Kunden beigestellt bzw. gemäß 
Vereinbarung vom Auftragnehmer erstellt wurde. Wenn bestimmte Funktionen 
bzw. Abläufe erst im IT-Pflichtenheft dargestellt bzw. näher spezifiziert werden, so 
ist auch dieses bei der Abfassung der Prüfliste mit heranzuziehen. 



223 HindellHörmannl Müllerl Schmied, Basiswissen Software-Projektmanagement, 18, 190. 

224 HindellHörmannl Müllerl Schmied, Basiswissen Software-Projektmanagement, 193 nen- 
nen als Beispiel die Aussage: „LED 3 soll nach Drücken von Taste 1 kurz blinken“; hier 
fehle (im Pflichtenheft) die Spezifikation, wie lange die LED blinken soll und mit wel- 
cher Blinkfrequenz. 
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Sind Teilabnahmen vorgesehen, sollte am Projektende eine Schlussabnahme er- 184 
folgen. In einem Integrationstest ist festzustellen, ob die verschiedenen Teile bzw. 
Module der Anwendung miteinander lauffähig sind . 225 Im Abnahmetest (an dem 
auch die Fachabteilung teilnehmen sollte) wird nicht nur die Integration geprüft, 
sondern die Gesamtheit der anwendungswesentlichen Funktionalitäten, also etwa 
der fehlerfreie und bruchlose Ablauf von Geschäftsprozessen. Teilabnahmen soll- 
ten mit Milestones verknüpft sein. Die Wirkung der Teilabnahme (Billigung von 
Leistungsteilen als im wesentlichen vertragsgerecht) kann entfallen, wenn der 
Integrationstest scheitert, da etwa Datenübernahmen zwischen den Modulen nicht 
möglich sind (dann hegt Nichterfüllung der gesamten Leistung vor, sofern z.B. ein 
Modul nicht isoliert genutzt werden kann), oder wenn nachträglich Anpassungen 
an erbrachten Leistungsteilen durchgeführt werden müssen. Den Vertragsparteien 
ist dringend zu raten, Verfahren bei Teil- und Schlussabnahmen ausdrücklich zu 
regeln und durchzuführen, da (durch Beginn der produktiven Nutzung) fingierte 
Abnahmen nicht selten Leistungs- oder Mitwirkungsdeßzite verdecken, die sich 
dann später im Scheitern des gesamten Projekts auswirken, das aus Sicht des Auf- 
traggebers dem Auftragnehmer zuzuordnen ist. Im Rahmen der Abnahmeprüfung 
kann es schließlich sinnvoll sein, einen Lasttest durchzuführen, mit dem der 
Durchsatz der Daten mit den Massedaten im Dialogbetrieb etwa hinsichtlich der 
Antwortzeiten geprüft wird. 

In die jeweilige Abnahmeprüfung sind auch alle Änderungen und Ergänzungen 185 
der Leistung einzubeziehen, die bis zum Zeitpunkt der jeweiligen Teilabnahme 
erfolgt sind. 

Für die Beurteilung festgestellter Fehler der Anbieterleistung wurde eine von den 186 
Auswirkungen des jeweiligen Fehlers her vorgenommene Fehlerklassifikation 
vorgeschlagen : 226 

• Der Fehler verhindert die Nutzung der Projektergebnisse. Beispiele: Der Fehler 
verursacht einen Systemabsturz, also einen Abbruch der Verarbeitung. Eine 
fehlerhafte Dokumentation verhindert die Nutzung wesentlicher Funktion- 
alitäten. 

• Der Fehler behindert die Nutzung der Projektergebnisse. Beispiele: Zur Fort- 
setzung der Nutzung muss eine Fehlerumgehung erfolgen. 



225 Müller-Hengstenberg/Wild, CR 1991, 327, 329 mit dem Hinweis, dass im Integrations- 
test meist nur wenige Haupttransaktionen getestet werden können und die noch aus- 
stehenden Testaktivitäten 20%-40% des gesamten Entwicklungaufwands ausmachen 
können. 

226 Streitz, IT-Projekte retten, 60. 
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• Der Fehler hat keine Auswirkung auf die Nutzbarkeit der Projektergebnisse. 
Beispiel: Rechtschreibfehler in der Dokumentation (oder in Quellcode-Kom- 
mentaren). 

Bei Verhinderung wie bei Behinderung der Nutzung kann nicht mehr von unwe- 
sentlichen Mängeln gesprochen werden und es besteht keine Abnahmepflicht des 
Auftraggebers (Umkehrschluss aus § 640 Abs. 1 S. 2 BGB). Bereits bei einzelnen 
solchen Mängeln kann eine Abnahme nicht mehr verlangt werden. 227 Auch unwe- 
sentliche Mängel begründen Ansprüche auf Nacherfüllung (Mängelbeseitigung 
oder Neuerstellung, §§ 634 Br. 1, 635 Abs. 1 BGB) oder Schadensersatz (§§ 634 Nr. 
4, 636 BGB), geben aber kein Rücktrittsrecht (§ 323 Abs. 5 S. 2 BGB). 

187 Werden Mängel festgestellt, soll aber trotzdem Abnahme erklärt werden, muss der 
Auftraggeber einen Vorbehalt bezüglich dieser Mängel erklären, andernfalls ver- 
liert er insoweit seine Mängelrechte (§ 640 Abs. 2 BGB). 

188 Eine Abnahme ist auch stillschweigend, etwa durch den produktiven Einsatz, 
möglich. 228 Freilich kann dies dann zu einem Verlust der Mängelrechte führen, 
soweit ein erforderlicher Vorbehalt nicht erklärt wird (was naheliegt, da bei Still- 
schweigen meist gerade keine Erklärung, auch keine zu einem Vorbehalt, abgege- 
ben wird). 

189 Oft ist bei komplexeren Projekten schon aus Zeitgründen keine vollständige Ab- 
nahmeprüfung sämtlicher Funktionen möglich. Hier wird unter Bezug auf eine 
80-20-Regel geraten, jedenfalls die 20% der Funktionen zu prüfen, die 80% des 
Produktivbetriebs abdecken. 229 Hierzu müssen freilich die Kernfunktionalitäten 
in der Abnahmespezifikation komplett erfasst werden. Für die restlichen 80% der 
Funktionen tritt mangels Kenntnis des Bestellers kein Verlust der Mängelrechte 
ein (arg. e § 640 Abs. 2 BGB). Jedoch sollte im Projektvertrag (oder im Anhang 
hierzu) geregelt werden, dass nur 20% der Funktionen geprüft werden (können) 
und diese auch bezeichnet werden. Im Abnahmeprotokoll sollte außerdem vor- 
sorglich (gemäß § 640 Abs. 2 BGB) erklärt werden, dass der Auftraggeber sich 
seine Mängelrechte bezüglich der nicht geprüften 80% der Funktionen vorbehält. 
Vorsorglich ist auch vertraglich zu regeln, dass hinsichtlich dieser 80% eine mögli- 
che (über § 651 BGB anzuwendende) kaufmännische Untersuchungs- und Rüge- 
pflicht nicht eingreift und für die 20% Kernfunktionen die Prüfliste und die Ab- 
nahmetermine auch insoweit verbindlich sind. 



227 Aus der technischen Sicht Streitz, IT-Projekte retten, 61. 

228 OLG München, Urt.v.24. 1.1990 - 27 U 901/88, CR 1991, 19. 

229 Streitz , IT-Projekte retten, 61. Hier wird an das sog. „Pareto-Prinzip“ angeknüpft, nach 
dem 20% der Fehlerursachen 80% der Fehlerwirkungen erzeugen ( Liggesmeyer , Soft- 
ware-Qualität, 15). 
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Bei Feststellung von Abweichungen sollten folgende Merkmale protokolliert 190 
werden : 230 

• Datum, Zeit 

• Beteiligte Personen 

• Unterscheiden zwischen Teilabnahme und Endabnahme 

• Fehlen der Dokumentation oder von Dokumentationsteilen 

• Verwendete Systemumgebung, soweit nicht aus der Abnahmespezifikation zu 
entnehmen 

• Bezeichnung der getesteten Komponente 

• Bezeichnung der Testprozedur mit zugehöriger Abnahmespezifikation 

• Beschreibung der Abweichung mit erwartetem und tatsächlichem Ergebnis 

• Reproduzierbarkeit des Fehlers 

• Auswirkungen des Fehlers (z.B. Abbruch der Verarbeitung, Inkonsistenz der 
Datenbank) 

• Ausdrucke der Systemangaben bzw. Fehlerbilder 

• Aufnahme der festgestellten Fehler in eine (von beiden Seiten geführte bzw. 
kontrollierte) Fehlerdatenbank, deren Eintragungen nach Prioritäten abgear- 
beitet werden 

• Unterschriften vom Kunden und Anbieter 

Festzulegen ist auch das Abnahmeverfahren, das meist die Form einer techni- 191 
sehen und anwendungsbezogenen Funktionsprüfung hat (z.B. Anlage einer elekt- 
ronischen Personalakte mit Alias-Namen). Hier müssen die für beide Vertragspar- 
teien verbindlichen Abnahme- bzw. Funktionskriterien im Projektvertrag oder in 
einer Anlage hierzu definiert sein, ebenso das Testverfahren und die Testdaten 
(die der Auftraggeber mangels abweichender Vereinbarung beibringen muss). 

Den Auftragnehmer kann bezüglich der Auswahl geeigneter Testdaten eine Auf- 
klärungs- und Hinweispflicht treffen. 

Anstatt der gemeinsamen Funktionsprüfung wird bei größeren Projekten häufig 192 
auch ein Probebetrieb als Form der Abnahme vereinbart. Auch diese Abnahme- 
form bedarf besonderer Vereinbarung, da sonst der Probebetrieb leicht als pro- 
duktive Nutzung zu beurteilen sein kann, die die Fiktion einer erfolgten Abnah- 
me ohne tatsächliche Billigung begründen würde. Klar und genau müssen hier 
Dauer und Umfang des Probebetriebs festgelegt werden, da erst nach Abschluss 
die Pflicht zur Erklärung der Abnahme entstehen darf, ebenso die Art der Tests, 
die vom Anbieter in ihrem Ergebnis als bindend akzeptiert werden müssen . 231 



230 Nach Streitz, IT-Projekte retten, 141; Ellenberger/Müller, Zweckmäßige Gestaltung von 
Hardware-, Software- und Projektverträgen, 66. 

231 Schneider/v.Westphalen/Redelcer, Software-Erstellungsverträge, D Rdn.236. 
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Das Ende des Probebetriebs sollte durch Erklärung des Auftraggebers festgestellt 
werden. 

193 Für die Durchführung einer Abnahmeprüfung und erst recht eines Probebetriebs 
der Software muss dem Auftraggeber bereits ein Recht zur Nutzung dieser Soft- 
ware eingeräumt sein. Fehlt eine Vereinbarung für diese testbezogene Nutzung, 
wird aber meist aus der Vereinbarung einer Abnahme-/Probebetriebsregelung zu 
schließen sein, dass diese Teil der (jedenfalls bei Vertragsbeginn) bestimmungs- 
gemäßen Benutzung (im Sinne von § 69 d Abs. 1 UrhG) sein sollen. Hierzu wird 
ein Vervielfältigen zwecks Installation gehören, nicht aber ein Bearbeiten, (Wei- 
ter-)Verbreiten oder öffentliches Zugänglichmachen. Vorzuziehen ist freilich eine 
klarstellende Regelung, welche Nutzungen in der Testphase durchgeführt werden 
dürfen. Festzulegen ist hier etwa auch die Anzahl der zugelassenen Arbeitsplätze 
bzw. (gleichzeitigen) Zugriffsrechte im Testbetrieb. Der Regelung bedarf auch das 
Vorgehen bei Scheitern der Abnahme, das zu einem restlosen De-Installieren der 
Software führt, also etwa auch dem (physikalischen) Föschen der Client-Software 
auf den Arbeitsplätzen. 

194 Erweist sich das Werk (also insbesondere die Software oder deren Änderung) in 
der Abnahme/Funktionsprüfung als im Wesentlichen vertragsgerecht, muss der 
Auftraggeber das Werk abnehmen (§ 640 Abs. 1 S. 1 BGB). Wegen unwesentlicher 
Mängel darf die Abnahme nicht verweigert werden (§ 640 Abs. 1 S. 2 BGB); frei- 
lich bestehen Nacherfüllungsansprüche fort (§§ 634 Nr. 1, 635 BGB). Dies muss 
grundsätzlich auch für Teilabnahmen gelten. Vorausgesetzt sind ausreichende 
Prüfmöglichkeiten; zumindest müssen Probeläufe ein zufriedenstellendes Ergebnis 
erbracht haben. 232 

195 Die Durchführung der Abnahme setzt meist die vorherige Durchführung von 
Schulungen und zuweilen eine Pilotinstallation voraus. 233 Das muss auch bereits 
für Teilabnahmen gelten. 

196 Der Anbieter kann dem Auftraggeber eine Frist zur Erklärung der Abnahme set- 
zen, wenn dieser hierzu verpflichtet ist. Nach Ablauf dieser Frist gilt die Abnahme 
als erfolgt (Abnahmefiktion des § 640 Abs. 1 S. 3 BGB) und die Vergütung fällig 
wird. 



232 OLG Düsseldorf, CR 1986, 1091. 

233 Streitz, IT-Projekte retten, 23. 
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Die Abnahme bewirkt: 234 1 97 

• Konkretisierung des abgenommenen Werks, 

• Verlust des Rechts auf Neuherstellung, Übergang von Erfüllungs- zu Mängelan- 
sprüchen, 

• Fälligwerden der Vergütung (§ 641 BGB), 

• Übergang der Vergütungsgefahr (§§ 644, 645 BGB), 

• Verjährungsbeginn für Mängelrechte (§ 634 a BGB), 

• Verlust des Rechts auf Nacherfüllung bekannter, nichtvorbehaltener Mängel 
(§ 640 Abs. 2 BGB), 

• Entfallen nichtvorbehaltener Vertragsstrafen (§ 341 Abs. 3 BGB), 

• Umkehr der Beweislast für Mängel (zulasten des Auftraggebers). 

b) Abnahmeregelungen bei Anwendbarkeit von Kaufrecht 

Abnahmeregelungen sollten - möglichst in der Form ausspezifizierter Funktions- 198 
Prüfungen 235 - unbedingt ausdrücklich für alle Projekte zur Erstellung und/oder 
Anpassung von Software vereinbart werden. Hierfür sind zwei zwingende Gründe 
anzuführen: 

Zum einen muss der Anbieter das Verfahren und Ergebnis ausführlicherer Funk- 199 
tionsprüfungen nur abwarten (und damit auch eine entsprechende Verzögerung 
in der Vergütungszahlung), wenn diese Funktionsprüfung im Projektvertrag aus- 
drücklich als Abnahmeform vereinbart wurde. Vorsorglich sollte hier auch eine 
Mitwirkung des Anbieters als Auftragnehmer an solchen Prüfverfahren geregelt 
werden, da der Auftraggeber diese Mitwirkung sonst nur schwer durchsetzen 
kann, so etwa die gemeinsame Feststellung zentraler Prüfergebnisse, ihre anbieter- 
seitige Bestätigung und Fixierung in einem von beiden Seiten zu unterzeichnen- 
den Abnahmeprotokoll. 

Zum anderen hat die Schuldrechtsmodernisierung 2002 im Bereich des Werkver- 200 
tragsrechts zu einer erheblichen, vorher nicht vorhandenen Rechtsunsicherheit 
geführt. § 651 BGB regelt nämlich, dass auf die Lieferung herzustellender oder zu 
erzeugender beweglicher Sachen Kaufrecht anzuwenden ist. Kaufrecht kennt aber 
keine Abnahme, 236 sondern nur die bloße Ablieferung. Sind diese Sachen nichtver- 
tretbar, gelangen neben dem Kaufrecht die §§ 642 (Mitwirkung des Bestellers), 643 



234 Witte in: Redeker (Hrg.), Handbuch der IT-Verträge, Abschnitt 1.4 Rdn. 105. 

235 Hierfür bereits Müller-Hengstenberg/Wild, CR 1991, 327, 328. 

236 Die in § 433 Abs. 2 BGB genannte „Abnahme“ enthält kein Billigungselement wie die 
Regelung des § 640 Abs. 1 S. 1 BGB, die eine Beurteilung als im Wesentlichen vertrags- 
gemäß beinhaltet, sondern wird nur als Entgegennahme ausgelegt (Palandt/Putzo, Bür- 
gerliches Gesetzbuch, § 433 Rdn. 43). 
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(Fristsetzung zur Mitwirkung), 645 (Haftung des Bestellers), 649 (Kündigungs- 
recht des Bestellers) und 650 BGB (Kostenanschlag) zur Anwendung, § 651 S. 2 
BGB, aber nicht die Abnahmeregelung des § 640 BGB. Sind die Sachen vertretbar 
(also gemäß § 91 BGB bewegliche Sachen, die im Verkehr nach Zahl, Maß oder 
Gewicht bestimmt zu werden pflegen), ist nur Kaufrecht anwendbar. Wird im 
Projektvertrag nun keine Regelung zur Abnahme getroffen, gilt die Leistung, etwa 
die zu entwickelnde Software, als mit Ablieferung erbracht, ab deren Zeitpunkt die 
Gewährleistungspflicht läuft (§ 438 Abs. 2 BGB), wobei außerdem die kaufmänni- 
sche Untersuchungs- und Rügeobliegenheit aus § 377 HGB (auch bei Software 237 ) 
zu beachten ist. Außerdem muss der Auftraggeber nach Kaufrecht die vereinbarte 
Vergütung (mangels abweichender Regelung) grundsätzlich bereits bei Vertrags- 
schluss leisten, hat aber bis zur Ablieferung der Software zumindest das Zurück- 
behaltungsrecht aus § 320 Abs. 1 S. 1 BGB. 238 Abschlagszahlungen können (soweit 
nicht vereinbart) aus Kaufrecht nicht verlangt werden. 239 

201 In der vertragsrechtlichen Literatur wird die Anwendung des § 651 BGB auf Soft- 
ware-Erstellung - entgegen dem Wortlaut - überwiegend abgelehnt . 240 Erste 
Rechtsprechung wendet ebenfalls Werkvertragsrecht an und stellt hierbei auf den 
Leistungsschwerpunkt im Vertrag ab (s. Rdn. 203). 

202 Ein Hauptargument gegen die Anwendbarkeit von § 651 BGB auf Software- 
Erstellungsverträge stützt sich darauf, dass Software die Sacheigenschaft im Sinne 
von § 90 BGB fehle, sie also keinen körperlichen Gegenstand darstelle. Dem steht 
die Rechtsprechung des BGH entgegen. Als „Sache“ gemäß § 90 BGB behandelt 
der BGH Computerprogramme jedenfalls dann, wenn sie auf Datenträger verkör- 
pert sind. 241 Deshalb kann, dem BGH zufolge, auf Application Service Providing 
Mietrecht unmittelbar angewendet werden, da die zeitlich begrenzt zum Gebrauch 
zugänglich gemachte Programmkopie auf dem Serverrechner des Anbieters ge- 
speichert ist 242 (und bleibt). Kaufrecht bzw. Mietrecht sind auch dann anwendbar, 
wenn das Computerprogramm nicht auf Datenträger übergeben, sondern online 



237 BGH, Urt.v.14.7.1993 - VIII ZR 147/92, ZIP 1993, 1394. 

238 Schneider/v.Westphalen/Redeker, Software-Erstellungsverträge, D Rdn.216. 

239 Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, 31. 

240 Für alle Schneider/v.Westphalen/Redefcer, Software-Erstellungsverträge, D Rdn. 82; 
Schneider/v.'W estphalen, a.a.O., B Rdn. 165 spricht sogar von einer absolut herrschen- 
den Meinung. 

241 So in der „ASP“-Entscheidung BGH, Urt.v.15. 11.2006 - XII ZR 120/04. Der BGH sieht 
Computerprogramme ausdrücklich als bewegliche Sache und auf deren Überlassung 
Kauf- bzw. Mietrecht (bei zeitlicher Begrenzng der Überlassung) als unmittelbar an- 
wendbar an (also nicht mehr nur, wie in früheren Entscheidungen, zumindest entspre- 
chend). Entscheidend sei die Verkörperung auf Datenträger. 

BGH, Urt.v.15.1 1.2006 - XII ZR 120/04. 



242 




B.8. Abnahmeregelungen 



69 



überlassen bzw. vom Kunden abgerufen wird; entscheidend ist allein, dass auf dem 
Zielrechner (des Kunden bzw. seines Providers) eine Programmverkörperung 
hergestellt und das Programm für den Erwerber nutzbar gemacht wird, wobei der 
wirtschaftliche Endzweck des Geschäfts gleich bleibt. 243 

Ein weiteres Argument lehnt die Anwendung von § 65 1 BGB jedenfalls in den Fällen 203 
ab, in denen die Erstellung oder Anpassung der Software den vertraglichen Leis- 
tungsschwerpunkt bildet, nicht deren Auslieferung. 244 Dies hatte auch der BGE1 
bereits dann angenommen, wenn die entgeltliche Schöpfung des Wertes im Vorder- 
grund steht, nicht die mit dem Warenumsatz verbundene Eigentumsübertragung. 245 
Werkvertragsrecht wurde etwa als anwendbar angesehen, wenn der Leistungs- 
schwerpunkt bei Installations- und Umstellungsarbeiten liegt, die die Software erst 
nutzbar machen sollen. 246 Diese Einstufung ist erst recht auf die Parametrisierung 
und Anpassungsprogrammierung von ERP-Software anwendbar. Dieses Abgren- 
zungskriterium der Frage nach dem Leistungsschwerpunkt ist außerdem unabhän- 
gig davon, ob Software als Sache einzuordnen ist, und wird bei Software-Projekten 
wohl in den meisten Fällen eine tragfähige Zuordnung gestatten. 

Als zulässig wird angesehen, in AGB die Abnahme und Zahlungsfähigkeit (etwa 204 
für die Zeitpunkte der Installation und Abnahme 247 ) abweichend vom gesetzlichen 
Vertragsbild des Kaufrechts zu regeln 248 und so den Projektvertrag wieder an das 
Werkvertragsrecht anzunähern. Allerdings können die Vertragsparteien in AGB 
nicht einfach pauschal Werkvertragsrecht als Vertragstypus wählen, wenn nach 
dem gesamten Leistungsbild (bzw. nach der schwerpunktbezogenen Beurteilung) 



243 So der BGH, Urt.v.18.10.1989 - VIII ZR 325/88, NJW 1990, 320 = CR 1990, 24 (noch 
zur Anwendbarkeit des früheren Abzahlungsgesetzes auf Abzahlungskauf) 

244 Thewalt , Der Softwareerstellungsvertrag nach der Schuldrechtsreform, 66. Müller- 
Hengstenberg/Krcmar, CR 2002, 549, 556 wenden Werkvertragsrecht an, wenn die indi- 
viduelle Lösungserarbeitung unter intellektueller Mitwirkung des Kunden im Vorder- 
grund stehen (unter Bezug auf BGH NJW 1998, 3197, 3199 für die prägende Leistung 
bei Montage einer Förderanlage) und Projekte angesichts ihrer längeren Dauer des 
Schutzes aus den Regelungen der §§ 632 Abs. 3, 632 a, 637 Abs. 3, 640, 641 a BGB be- 
dürfen. 

245 BGH, Urt.v.24.11.1976 - VIII ZR 137/75, WM 1977, 79 (für § 651 a.F.). 

246 OLG Hamm, Urt.v. 10.3.2006 - 12 U 58/05, CR 2006, 442. Ähnlich hat das OLG Köln, 
Urt.v.10.3.2006 - 19 U 160/05, CR 2006, 440 noch zum früheren Recht auf das Über- 
wiegen des werkvertraglichen Moments bei geschuldeter Anpassung in zahlreichen 
Funktionen abgestellt. 

247 Schneider/v.Westphalen/Redeker, Software-Erstellungsverträge, D Rdn.223. 

248 Schneider/v. Westphalen, Software-Erstellungsverträge, B Rdn. 165b empfiehlt aus- 
drücklich eine „Neutralisierung“ der Rechtsfolgen des § 651 BGB. Eigentlich sollte es 
nicht Aufgabe von Vertragsparteien sein, derartige Reparaturarbeiten an neuen Geset- 
zesbestimmungen vornehmen zu müssen, um deren Auswirkungen abzufangen. 
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Kaufrecht anwendbar ist. Zweifelhaft erscheint auch, ob ein entsprechend umfas- 
sendes, werkvertragsnahes Pflichtenprogramm in Einkaufs-AGB des Auftragge- 
bers wirksam geregelt werden kann. Ein solcher Regelungskomplex könnte in 
seiner Gesamtheit als unangemessen benachteiligend zu beurteilen sein, da er mit 
wesentlichen Grundgedanken des Kaufrechts nicht zu vereinbaren wäre, auf das § 
651 BGB gerade verweist (§ 307 Abs. 2 Nr. 1 BGB). Allerdings ist Kaufvertrags- 
recht wesenstypisch mit einem punktuellen Leistungsaustausch verbunden; eine 
individuelle Erstellungspflicht gehört deshalb nicht zum Pflichtenprogramm des 
Verkäufers, während sie in IT-Projekten gerade die zentrale Leistungspflicht bil- 
det. Software-Projekte und Kaufrecht passen damit nicht recht zusammen. Der 
Auftraggeber sollte für Projekte zur Software-Entwicklung also keine „Einkaufs“- 
AGB verwenden, sondern getrennte Projekt- AGB, in denen der Leistungsschwer- 
punkt der Erstellung bzw. Anpassung der Software in den Mittelpunkt gestellt 
wird. 



205 j)i e Vereinbarung eines Abnahmeerfordernisses (mit angeknüpfter Zahlungsfäl- 
ligkeit) sowie die Aufgliederung in Teilabnahmen und Teilvergütungen bei Er- 
reichen von Milestones erscheint auch im Rahmen von Kaufrecht als zulässig 249 
(da die kaufvertragstypischen Pflichten aus § 433 Abs. 1 BGB unberührt bleiben) 
und angesichts der vom novellierten § 651 BGB geschaffenen Rechtsunsicherheit 
auch unbedingt anzuraten. Pflicht der Geschäftsleitung ist damit sicherzustellen, 
dass - gerade im Tlinblick auf eine mögliche Anwendung des § 651 BGB - eine 
zudem ausreichend spezifizierte Abnahmeregelung im Projektvertrag getroffen 
wird. 

Vorsorglich sollte außerdem ein durch die Entwicklungsleistung zu erreichendes 
konkretes Ziel und eine definierte Verfahrensweise als vertraglich geschuldeter 
Leistungserfolg nach Möglichkeit individualvertraglich (oder zumindest in einer 
die AGB ergänzenden Individualvereinbarung) festgelegt und ausführlich spezi- 
fiziert werden. Dieses Leistungsziel muss der Anbieter dann - unabhängig von 
der Anwendbarkeit von Kaufrecht über § 651 BGB - erreichen. 



206 hi Individualvereinbarungen ist es grundsätzlich problemlos zulässig, das Ab- 
nahmeerfordernis im Vertrag festzulegen (§ 305 b BGB), zumindest, wenn an 
sachgerechte Prüfkriterien angeknüpft wird. Gleiches gilt für Individualvereinba- 
rungen zu Schulungen und Einweisungen der Mitarbeiter des Auftraggebers als 



249 Ähnlich i.E. Schneider/v.Westphalen/Redeker, Software-Erstellungsverträge, D Rdn.251 
ff. 





B.9. Herausgabe der Quellformate (Sourcen) erstellter Programme 



71 



Abnahmevoraussetzung, aber auch zu dessen Mitwirkungspflichten 250 und über 
die Erstellungspflicht des Anbieters als solche. 

Soweit § 651 BGB auch auf die Anpassung von Standardsoftware als anwendbar 207 
angesehen wird, 251 erscheint eine zusätzliche Differenzierung als hilfreich: Erfolgen 
die Anpassungen bereits beim Anbieter, der dann die an die Kundenbedürfnisse 
angepasste Software überhaupt erst ausliefert, könnte § 651 BGB anzuwenden sein 
(die Sachqualität von Software unterstellt). Liefert der Anbieter aber zunächst die 
Standardsoftware und installiert er sie, um sie dann in Abstimmung mit dem 
Kunden auf dessen IT-System(en) erst anzupassen, so kann in dieser Anpassung 
(z.B. als eigener Projektstufe) eine trennbare, eigenständige Werkleistung zu se- 
hen sein, auf die Werkvertragsrecht uneingeschränkt anwendbar ist, da die Anbie- 
terleistung hier in Bezug auf eine bereits bestehende Sache des Bestellers erbracht 
wird. 252 Zu einem vergleichbaren Ergebnis gelangt man, wenn man bei einer 
nichtabgestuften Leistung nicht die Lieferung eines Exemplars der Standardsoft- 
ware als Schwerpunkt des geschuldeten Erfolgs ansieht, sondern die Anpassung an 
die individuellen Kundenbedürfnisse 253 (womit das Erfordernis einer Trennung 
der Leistungsstufen entfällt). Hier ist Werkvertragsrecht uneingeschränkt an- 
wendbar. Das gilt schließlich erst recht, wenn der geschuldete Leistungserfolg auf 
die erforderte Anpassung der betrieblichen Abläufe ausgerichtet wird und der 
Software-Einsatz nur ein (vom Werkunternehmer grundsätzlich frei wählbares) 
Mittel hierfür ist. 

9. Herausgabe der Quellformate (Sourcen) erstellter Programme 

Erhält der Auftraggeber Standardsoftware überlassen, kann er in der Regel nicht 208 
die Überlassung auch der Sourcen der Standardsoftware verlangen, 254 wenn nichts 
Abweichendes vereinbart wurde. Soweit der Auftraggeber hingegen die gesamte 
Entwicklung einer Individualsoftware voll vergütet, erwirbt er grundsätzlich alle 
Nutzungsrechte am gesamten Code, also auch an Sourcen, insbesondere bei ge- 
planter eigener Weitervermarktung. 255 Diese Fallkonstellation ist aber heute eher 
die Ausnahme. Anbieter verwenden vielmehr bestimmte Software-“Teile“, z.B. 
ausführbare Programme, aus anderen Aufträgen weiter (Software-Wiederver- 



250 Schneider/v. Westphalen, Software-Erstellungsverträge, B Rdn. 165c, 165d. 

251 S. etwa Schneider/v. Westphalen, Software-Erstellungsverträge, B Rdn. 75; Schneider/ 
v.Westphalen/VD'fzeZ, Software-Erstellungsverträge, F Rdn. 87. 

252 Palandt/Sprau, Bürgerliches Recht, § 651 Rdn. 4. 

253 Palandt/Sprau, a.a.O. 

254 OLG München, Urt.v.16.7.1991 - 25 U 2586/91, CR 1992, 208 (Keine Verpflichtung zur 
Sourcen-Herausgabe, da im Vertrag nur Objektcode erwähnt). 

BGH, Urt.v.16. 12.2003 - X ZR 129/01, CR 2004, 490. 



255 
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wendung). Außerdem nehmen sie an komplexen Softwaresystemen (etwa zur 
Unternehmenssteuerung) oft nur Anpassungen vor. Ausschließliche Nutzungs- 
rechte wird der Kunde hier nur an den individuell entwickelten Software-Teilen 
erwerben können, an der jeweiligen Gesamtsoftware aber nur einfache Nutzungs- 
rechte (da der Anbieter seine Software sonst nicht mehr weiterverwerten könnte, 
sondern immer wieder von Grund auf neu schreiben müsste). Der Umfang der 
Nutzungsrechte sollte hier genau definiert sein. Außerdem ist die Höhe der Ver- 
gütung zu prüfen, da der Auftraggeber die Rechte an der Software nicht uneinge- 
schränkt eingeräumt erhält. 

209 Die Anbieterverpflichtung zur Herausgabe der Sourcen kann in AGB abbedungen 
werden . 256 Hieraus ist aber nicht der Umkehrschluss zu ziehen, dass bei Fehlen 
eines solchen Ausschlusses die Quellformate generell herauszugeben wären. 

210 Auch bei Individualentwicklungen wird der Anbieter die Herausgabe der Sourcen 
so lange nicht schulden, wie er noch Pflegeleistungen oder Mängelbeseitigungen 
an der Software zu erbringen hat 257 oder diese weiterentwickeln soll. Bei Ende der 
Pflege- bzw. Gewährleistungsverpflichtung kann der Quellcode dann herauszuge- 
ben sein, allerdings nicht in der alten, bei Vertragsunterzeichnung vorhandenen, 
nicht mehr uneingeschränkt verwendbaren, sondern in der aktuellen, durch die 
Pflege angepassten Fassung; dies bedarf aber besonderer Vereinbarung. 

211 Zumindest eine Hinterlegung bei einem Dritten wird aber möglich sein. Freilich 
muss der Programmcode in seiner endgültigen Gestalt vorliegen, d.h. lauffähig 
sein. Hierfür können regelmäßige Aktualisierungen erforderlich sein, also etwa die 
(kostenaufwendige) Hinterlegung mit Codeprüfung für jedes neue Update. 

212 Die Übergabe der Sourcen hilft dem Auftraggeber bei Anbieterinsolvenz nur 
begrenzt . 258 Die reine Programmnutzung setzt nämlich nicht die Verfügung über 
die Quellformate voraus. Die Sourcen werden nur für Änderungen oder Ergän- 
zungen am Programmcode benötigt. Solche Eingriffe in den Code wird die IT- 
Abteilung des Auftraggebers meist nicht durchführen können bzw. wollen. Vom 
insolventen Anbieter ist ebenfalls keine weitere Unterstützung zu erwarten, wenn 
der Insolvenzverwalter Nichterfüllung laufender Pflegeverträge wählt. Damit 
bleibt aber nur die Beauftragung anderer Anbieter, die jedoch den Quellcode meist 
erst ausführlich und kostenaufwendig analysieren werden, um ihr eigenes Haf- 
tungsrisiko zu begrenzen. 



256 LG Köln, Urt.v. 15.4.2003 - 85 O 15/03, JurPC Web-Dok. 232/2003. 

257 BGH, Urt.v.30.1.1986 - I ZR 242/83, NJW 1987, 1259. 

258 Zu den Kundenrechten in der Anbieterinsolvenz s. Rdn. 396. 





B.10. Zulässige Nutzung „gebrauchter“ Software? 



73 



Noch weniger hilfreich ist im Insolvenzfall eine Hinterlegung bei einem Dritten 213 
(etwa einem Notar). Die Sourcen bleiben grundsätzlich auch bei Hinterlegung Teil 
der Insolvenzmasse. 

1 0. Zulässige Nutzung „gebrauchter" Software? 

Am Markt finden sich Angebote, bereits an einen Kunden eingeräumte Nutzungs- 214 
rechte an Software auf andere Anwender zu übertragen. Hierbei soll teilweise ein 
Preisvorteil von etwa 20% gegenüber dem „Neupreis“ zu erzielen sein. Betont sei 
vorab, dass Software generell nie „gebraucht“ sein kann (sondern allenfalls der 
Datenträger, auf den sie kopiert ist); eine physische Abnutzung am Code selbst 
tritt nicht ein. Erst recht kann ein Nutzungsrecht nicht gebraucht sein. 

Urheber- und damit lizenzvertraglich zulässig sind tatsächliche Weiterveräuße- 215 
rungen eines kundenseits erworbenen Software-Exemplars an einen Dritten, aller- 
dings nur, wenn der Originaldatenträger übergeben wird und der Veräußerer 
gleichzeitig alle auf seinem IT-System vorhandenen Programmkopien löscht, also 
auch Sicherungskopien. Bei kaufweisen Weiterüberlassungen an Folgeerwerber 
kann sich zulässigerweise eine Veräußerungskette bilden. Das Verbreitungsrecht 
des Berechtigten (Urheber oder durch diesen berechtigte Vertriebspartner) ist hier 
mit der Erstveräußerung an den Ersterwerber erschöpft. Der Berechtigte darf 
außerdem weder dem Ersterwerber noch Folgeerwerbern das Laden in den Rech- 
ner und weitere für die bestimmungsgemäße Benutzung erforderliche Vervielfäl- 
tigungen untersagen. Zwar tritt bezogen auf das Vervielfältigungsrecht keine 
Rechtserschöpfung ein, doch würde ein entsprechendes Vervielfältigungsverbot 
gegenüber Folgeerwerbern den Erschöpfungsgrundsatz unterlaufen. Der Erst- und 
v.a. ein Folgeerwerber können nämlich mit einem berechtigt erworbenen Pro- 
grammexemplar wenig anfangen, wenn sie es nicht einmal in ihre Rechner laden 
dürfen. 259 Im Vertrag zwischen Berechtigtem und Ersterwerber können freilich 
Verbreitungs- und Kopierverbote vereinbart werden (wobei die Zulässigkeit AGB- 
rechtlich zu prüfen bleibt und wohl für Vervielfältigungsverbote zu verneinen ist, 
die die bestimmungsgemäße Programmbenutzung einschränken oder verhin- 
dern), doch binden solche schuldrechtlichen Vereinbarungen mangels dinglicher 
Wirkung nicht Folgeerwerber. 

Gute Gründe sprechen allerdings dafür (wenngleich hierzu gefestigte Rechtspre- 216 
chung noch nicht vorliegt), dass eine Weiterveräußerung auf Datenträger unzuläs- 
sig ist, wenn der Veräußerer das Software-Exemplar auf diesem Datenträger durch 
Online-Download heruntergeladen und abgespeichert hat. Diese Online-Übertra- 



259 Dreier/ Schulze, UrhG, § 69 c, Rdn. 25; Baus, MMR 2002, 14, 16. 
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gung stellt nämlich keine Verbreitung im Sinne von § 69 c Nr. 3 S. 2 UrhG dar. 260 
Diese Verbreitung erfordert eine Überlassung auf Datenträger und eine Verkörpe- 
rung während des gesamten Überlassungs- sowie Weiterverbreitungsvorgangs, 261 
nicht nur eine Verkörperung durch Abspeichern erst im Zielrechner der Übertra- 
gung. Das Angebot zum Herunterladen und Bereithalten von Dateien hierfür ist 
vielmehr als öffentliches Verfügbarmachen gemäß den §§ 19 a, 69 c Nr. 4 UrhG 
einzustufen, das zu keiner Rechtserschöpfung des Verbreitungsrechts führen 
kann. 262 Die Rechtserschöpfung bezieht sich nur auf immaterielle Rechtsgüter, die 
in einem Gegenstand verkörpert sind, 263 also etwa in einem Datenträger. Die 
Rechtserschöpfung lässt andere Ausschließlichkeitsrechte des § 69 c UrhG als das 
Verbreitungsrecht unberührt. 264 

217 Eine analoge Anwendung des Erschöpfungsgrundsatzes auf das Online-Ver- 
fügbarmachen ist außerdem bereits EG-rechtlich nicht möglich, da hierdurch die 
gemeinschaftsweit einheitlich geregelte Erschöpfungswirkung (Art. 4 Abs. 2 der 
Richtlinie 2001/29/EG zum Urheberrecht und den verwandten Schutzrechten in 
der Informationsgesellschaft) unzulässig national ausgeweitet würde. 265 Die ge- 
nannte Urheberrechtsrichtlinie muss (wie andere EG-Richtlinien auch) so in nati- 
onales Recht umgesetzt werden, dass der Einzelne sich über den Umfang seiner 
Rechte und deren Durchsetzbarkeit vor den Gerichten Gewissheit verschaffen 
kann. 266 Hierzu ist erforderlich, dass die Regelung im nationalen Recht klar und 
transparent erfolgt, also materiell gleichwertig ist. Diese Gleichwertigkeit wird 
nicht erreicht, wenn nur die nationale Rechtsprechung ein Recht abgrenzt und 
ausgestaltet. Eine sich erst schrittweise herausbildende Rechtsprechung etwa zu 



260 Schricker/Loewenheim, Urheberrecht, 3. Aufl. 2006, § 17 Rdn. 37. 

261 Hoeren, Gutachten zur Frage der Geltung des urheberrechtlichen Erschöpfungsgrund- 
satzes bei der Online-Übertragung von Computerprogrammen v. 17.2.2006, 6. 

262 LG München I, Urt.v. 19.1.2006 -70 23237/05, CR 2006, 159 = MMR 2006, 175. 

263 OLG München, Urt.v. 3.8.2006 - 6 U 1818/06, CR 2006, 655 = JurPC Web-Dok. 
141/2006 (Berufungsentscheidung zu LG München I, Urt.v. 19.1.2006 -70 23237/05. 

264 Für die Datenbank-Richtlinie 96/9/EG BGH, Urt.v. 21.4.2005 - I ZR 1/ 02, GRUR 2005, 
940, 942 = CR 2006, 51 - Marktstudien; OLG Köln, Urt.v. 28.10.2005 - 6 U 172/03, CR 
2006, 368, 372 unter Verweis auf Erwägungsgrund 35 der RL; Huppertz, CR 2006, 145, 
146. Erwägungsgrund 32 verweist auf den entsprechenden Grundsatz der verbindlichen 
gemeinschaftsweit einheitlichen Geltung der ausschließlichen Rechte für die Richtlinie 
zum Urheberrecht in der Informationsgesellschaft 2001/29/EG. Bejaht wurde eine ana- 
loge Anwendung durch das LG Hamburg, Urt.v. 29.6.2006 - 315 O 343/06, CR 2006, 
812 Anm. Grützmacher. 

265 Zwar spricht viel dafür, vom Ergebnis her Übergabe auf Datenträger und Download 
gleichzusetzen, da jedes Mal eine Programmkopie auf den Rechner gelangt ( Spindler , 
GRUR 2002, 105, 110; Koch, GRUR 1997, 417, 426), doch schließt die richtlinienbasier- 
te Gestaltung des § 69 c UrhG einen solchen Analogieschluss allein im nationalen Recht 
gerade aus. 

266 EuGH, Urt.v.30.5.1991 - C-361/88, Slg. 1991, 1-2567 - Kommission/Deutschland. 
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einer analogen Anwendung des Grundsatzes der Erschöpfungswirkung auf online 
erfolgende Übertragungsakte kann eine nationale Transformationsregelung nicht 
gleichwertig ersetzen und auch eine als erforderlich angesehene analoge Anwen- 
dung nicht tragen, da bis zur (u.U. langdauernden) Ausbildung einer gewissen 
Festigung und Stetigkeit der Rechtsprechung für die Berechtigten nicht hinrei- 
chend bestimmt und klar ist (und sein kann), welche Rechte sie denn nun gesi- 
chert haben. 267 Hinzu kommt, dass der nationalen Rechtsprechung generell der 
zwingende Charakter im Sinne einer Sperrwirkung des normativen Umsetzungs- 
akts fehlt; 268 das muss auch für Fälle einer Analogiebildung im Richtlinienrecht 
gelten. Bei rein nationaler Ergänzung der Richtlinienregelungen durch Analogie- 
bildung droht außerdem eine Zersplitterung des Binnenmarkts und rechtliche 
Inkohärenz (Erwägungsgrund 6 Satz 2). Diese Überlegungen kommen umso mehr 
zum Tragen, als die Richtlinie 2001/29/EG schließlich tatsächlich durchaus in 
nationales Recht umgesetzt wurde, dies aber ohne das Einführen einer Erschöp- 
fungswirkung durch Online-Zugänglichmachen. 

Diese Überlegungen gelten auch und erst recht für jede einzelstaatliche Ergänzung 218 
von in nationales Recht transformierten Richtlinienregelungen durch Analogiebil- 
dung allein im Rahmen des nationalen Rechts. Der Richtliniengeber weist in Erwä- 
gungsgrund 25 der Richtlinie 2001/29/EG ausdrücklich auf die Notwendigkeit hin, 
die Rechtsunsicherheit bezüglich netzvermittelter Übertragung urheberrechtlich 
geschützter Werke in gemeinschaftsweit einheitlicher Weise zu beseitigen. Es soll 
also jeder Berechtigte in jedem Mitgliedsstaat dieselben Rechte haben (bzw. nicht 
haben). Dies verbietet zwingend, etwa in Deutschland für das aus der Richtlinie 
transformierte deutsche Urheberrecht mittels der Rechtsprechung eine Erschöp- 
fungswirkung des Verbreitungsrechts des Urhebers oder des von ihm Berechtigten 
auch für Online-Übertragungen einzuführen, da diese Erschöpfungswirkung nur 
in Deutschland eintreten könnte. 

Die angeführten EG-rechtlichen Grundsätze zur Bindungswirkung von Richtlinien 219 
sind uneingeschränkt auch auf Richtlinien zur Regelung der Rechte an geistigem 
Eigentum anwendbar. Auch insoweit dürfen Analogieschlüsse nicht einzelstaatlich 
divergierend gezogen werden und gemeinschaftsweit einheitliche Nutzerrechte 
nicht aufsplittern. Es bleibt vielmehr nur eine Anpassung des EG-Sekundärrechts 
oder eine Auslegung durch europäische Gerichte. Auf die Frage, ob der nationale 



267 EuGH, Urt.v.6.5.1980 - Rs 102/79, Slg. 1980, S. 1486 - Kommission/Deutschland; 
EuGH, Urt.v. 23.5.1985 - Rs 29/84, Slg. 1985, S. 1661, 1673 - Kommission/Deutsch- 
land; EuGH, Urt.v. 25.11.1986 - verb.Rs 201 u. 202/85, Slg. 1986, S. 3480, 3486 - Kom- 
mission/Belgien; EuGH, Urt.v. 9.4.1987 - Rs 363/85, Slg. 1987, S. 1733, 1740, 1742 - 
Kommission/Italien; EuGH EuZW 1997, 348, 350 - Kommission/Deutschland; zum 
Problemkreis s. auch Koch , ZUM 2001, 839, 845. 

268 Dreher, EuZW 1997, 521. 
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Gesetzgeber bei der Umsetzung der Richtlinie in dieser eine planwidrige Lücke 
(Voraussetzung des Analogieschlusses) übersehen hat, kann es nicht ankommen, 
wenn die Umsetzung richtlinienkompatibel erfolgt. Hätte der Gesetzgeber eine 
(vermeintliche) Lücke erkannt, wäre er im Umsetzungsakt doch nicht berechtigt 
gewesen, diese Lücke allein auf einzelstaatlicher Ebene zu füllen. Vielmehr war er 
gehalten, die Richtlinie mitsamt der planwidrigen Lücke (Nichtregelung der Er- 
schöpfung des Verbreitungsrechts bei der Online-Übertragung von urheberrecht- 
lich geschützten Werken) in nationales Recht umzusetzen; hier würde zwar die 
Richtlinienregelung eine planwidrige Lücke aufweisen (immer unterstellt, dass der 
Richtliniengeber den Erschöpfungsgrundsatz überhaupt ausgeweitet hätte, wäre 
ihm das Problem bewusst gewesen), das Umsetzungsgesetz hingegen eine planmä- 
ßige Lücke, 269 was einem Analogieschluss den Boden entzieht. Über die Auslegung 
der Richtlinie könnte nur der EuGH entscheiden, 270 nicht ein nationales Gericht. 

220 Regelungsziel der Richtlinie 2001/29/EG war zudem, den WIPO -Urheberrechts- 
vertrag (und den WIPO-Vertrag über Darbietungen und Tonträger) nach der Ver- 
tragsratifikation in das Gemeinschaftsrecht umzusetzen. 271 Der WIPO -Urheber- 
rechtsvertrag (WCT) enthält nun aber unter der Überschrift „Vereinbarte 
Erklärungen“ zu den Art. 6 und 7 die Feststellung, dass sich die Bestimmungen 
zum Verbreitungsrecht (Art. 6 WCT) und zum Vermietrecht (Art. 7 WCT) aus- 
schließlich auf Vervielfältigungsstücke beziehen, die als körperliche Gegenstände 
in Verkehr gebracht werden können. Vor diesem Hintergrund bestand schon für 
den Richtliniengeber keine Veranlassung oder auch nur Möglichkeit, Online- 
Übertragungen urheberrechtlich geschützter Werke (und die Erschöpfung des 
Verbreitungsrechts an diesen) in den Art. 4 der RL 2001/29/EG einzubeziehen. 
Dies spricht dagegen, dass auf der Richtlinienebene überhaupt eine planwidrige 
Regelungslücke aufgetreten ist. Damit bleibt kein Raum für eine analoge Anwen- 
dung des Erschöpfungsgrundsatzes auf Online-Übertragungen von Computerpro- 
grammen. 

221 Auch kann das Argument nicht überzeugen, dass von der Wirkung des Erschöp- 
fungsgrundsatzes nur Dienstleistungen ausgeschlossen seien, nicht aber ein online 
abgewickeltes Warentauschgeschäft in der Form eines Rechtskaufs gemäß § 453 
Abs. 1 2.Alt BGB. 272 Merkmal der Online-Abwicklung ist gerade, dass eben kein 



269 So ausdrücklich Hoeren, Gutachten zur Frage der Geltung des urheberrechtlichen Er- 
schöpfungsgrundsatzes bei der Online-Übertragung von Computerprogrammen v. 
17.2.2006, 8. 

www.usedsoft.com/pdf/Rechtsgrundlagen/Gutachten_Prof_Hoeren_Online_Erschoepf 

ung.pdf. 

270 Lehmann, Urteilsanm. zu OLG München, Urt.v. 3.8.2006, CR 2006, 655. 

271 S. näher Lehmann, CR 2003, 553. 

272 Sosnitza, K8cR 2006, 206, 208. 
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„Vervielfältigungsstück“ (im Sinne von Art. 4 Abs. 2 RL 2001/29/EG) auf Daten- 
träger verkörpert überlassen, sondern nur das digitale Format übertragen wird. 

Nur wenn die Verkörperung auch während des Überlassungsakts erhalten bliebe, 
könnte eine Verbreitung vorliegen und eine Erschöpfung des Verbreitungsrechts 
eintreten. 

Weiter vermerkt Erwägungsgrund 29 zur Richtlinie 2001/29/EG zwar, dass sich 222 
die Frage der Erschöpfung weder bei Dienstleistungen allgemein noch bei Online- 
Diensten stellt. Zweifelhaft erscheint aber, ob hieraus ableitbar ist, dass Erwä- 
gungsgrund 29 Online-Übertragungen von dauerhaft vom Übertragungsempfän- 
ger zu nutzenden Computerprogrammen nicht betreffe. 273 Vielmehr konfrontiert 
die Richtlinie derartige Online-Übertragungen gerade mit Fällen, in denen geisti- 
ges Eigentum verkörpert auf Datenträgern überlassen wird (Erwägungsgrund 29 
S. 3). Dies kann eine Differenzierung nach Art der online übertragenen Werke 
gerade nicht stützen. Dass die Anknüpfung an den Dienstleistungsbegriff zum 
Zwecke der Abgrenzung des Geltungsbereichs des Erschöpfungsgrundsatzes we- 
nig hilfreich ist, ergibt sich i.Ü. aus dem Umstand, dass Erwägungsgrundsatz 29 S. 

2 sogar die (offline und auf Datenträger erfolgende) Vermietung als Dienstleistung 
bezeichnet. Erschöpfung scheidet hier gerade nicht aus, weil eine Dienstleistung 
vorliegt, sondern wegen des Fehlens einer dauerhaften Rechtsübertragung. 

Unabhängig von der Unzulässigkeit einer analogen Anwendung des Grundsatzes 223 
der Erschöpfung des Verbreitungsrechts auf nichtverkörperte Weitergaben ist der 
Ersterwerber nicht berechtigt, die mittels Online-Übertragung erhaltene Pro- 
grammkopie anstatt auf Datenträger seinerseits online zugreifbar zu machen. 274 
Deshalb bedarf sowohl ein Weiterverbreiten des online erhaltenen Programmex- 
emplars auf Datenträger als auch ein online erfolgendes Weiterübertragen dieses 
Exemplars der Zustimmung des Berechtigten. Außerdem wird bei Online-Über- 
tragung nicht das online erhaltene Programmexemplar selbst weiterübertragen, 
sondern der zugreifende Nutzer erstellt durch den Abruf auf seinen Rechner für 
sich eine zusätzliche Kopie, 275 während der Online-Zugriff auch nach einem Abruf 
für andere Nutzer erhalten bleiben kann. 

Schließlich wird eine Praxis nicht vom Erschöpfungsgrundsatz gedeckt, nach der 224 
der Ersterwerber nur seine Registrier-/Lizenznummer (über Händler) anderen 
Anwendern zugänglich macht und ein damit verbundenes Nutzungsrecht über- 
tragen will. Mit Eingabe der Lizenznummer kann der Empfänger dann eine Kopie 



273 So Hoeren, Gutachten zur Frage der Geltung des urheberrechtlichen Erschöpfungs- 
grundsatzes bei der Online-Übertragung von Computerprogrammen v. 17.2.2006, 11. 

274 Schricker/Loewenheim, Urheberrecht, § 69 c Rdn. 33. 

275 Walter, in: v. Lewinski/Walter/Blocher/Dreier/Daum/Dillenz, Europäisches Urheber- 
recht, Kap. II Rdn. 84 Info-RL. 
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direkt vom Software -Anbieter herunterladen. Hier liegt nicht einmal ein Online- 
Zugänglichmachen einer Werkkopie durch den Ersterwerber vor, der bei Weiter- 
gabe der Nummern seine Programmkopien löscht. Ein Zugänglichmachen erfolgt 
vielmehr über die Website des Software- Anbieters. Dieser nimmt durch Eingabe 
der Lizenznummer seitens des Folgenutzers an, der bei ihm registrierte bisherige 
Inhaber dieser Nummer wolle ein Programmexemplar abrufen. Eine Zustimmung 
des Anbieters zur Weitergabe dieser Nummer an den Folgenutzer kann deshalb 
nicht angenommen werden. Auch liegt in der Übertragung von der Website des 
Anbieters gerade keine Weiterübertragung im Verhältnis Erst- und Folgeerwerber 
vor, für die allein die Freistellung vom Zustimmungsbedürfnis zu prüfen wäre. Da 
keine Übergabe eines verkörperten Werkexemplars erfolgt, kommt eine Erschöp- 
fung des Verbreitungsrechts schon deshalb nicht in Betracht. 276 Da außerdem kein 
Zugänglichmachen durch den Erstnutzer gegenüber dem Folgenutzer stattfindet, 
scheidet schon deshalb eine analoge Anwendung des Erschöpfungsgrundsatzes auf 
die Online-Übertragung vom Anbieter zum Folgenutzer aus. 

1 1 . Service Level Agreements - Vereinbarungen abgestufter Anbieterleistungen 

225 Service Level Agreements (SLAs) lassen sich auf die Pflege von Software anwenden 
(s. Rdn. 234), aber auch die Wartung von Hardware, etwa Web-Serverrechner, 
oder die Verfügbarkeitsmerkmale für Internet- Anbindungen. 

226 Der Begriff des „Service Levels“ ist vertragsrechtlich (und überhaupt rechtlich) 
nicht definiert. 277 Als „Levels“ werden in der Praxis meist an Kennzahlen orien- 
tierte Leistungsabstufungen bezeichnet, ohne dass hierfür aber eine Definition 
besteht. Aus dem Gesetz können nur sehr begrenzt Regelungen zum Füllen ver- 
bliebener Vereinbarungslücken im Vertrag herangezogen werden; so wird etwa bei 
Fehlen einer Festlegung von Qualitätsmerkmalen einer Leistung das Erbringen 
einer Leistung „mittlerer Art und Güte“ geschuldet, die aber meist nicht den An- 
forderungen des Kunden entsprechen wird, etwa im Bereich der IT-Sicherheit. 278 
Die Existenz bestimmter objektiver Standards ist für eine Vereinbarung von Servi- 
ce Levels nicht zwingend erforderlich, solange zumindest die Vertragsparteien von 
einem gemeinsamen (am besten im Vertrag zu definierenden) Verständnis ausge- 
hen. Messungen müssen aber objektiviert möglich sein (damit sie im Streitfall 
auch vom gerichtlich bestellten Sachverständigen nachvollziehbar sind). 



276 Ähnlich Heydnl Schmidl, K&R 2006, 74, 75. 

277 Schneider/v.Westphalen/Pefer, Software-Erstellungsverträge, G Rdn. 358; Hörl/Häuser , 
CR 2003,713. 

278 Schreibauerl Taraschka, CR 2003, 557, 558. 
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Bei der Präzisierung der zu erbringenden Leistungen kann auf die typisierten Re- 227 
gelungspunkte nach ITIL (s. Rdn. 673) und ISO 20000-2 (s. Rdn. 716) zurückge- 
griffen werden. ITIL und ISO 20000 enthalten freilich nicht fertig vorformulierte 
Vertragsklauseln, sondern zum Standard gewordene Auflistungen typischer Rege- 
lungspunkte, zu denen zumindest V ereinbarungen zu treffen sind. 

Präzise und transparent sollten Qualität (z.B. Verfügbarkeit) und Leistungszeit- 228 
punkte geregelt werden, ebenso die Kontrolle mittels Reporting (Möglichkeit der 
jederzeitigen kundenseitigen Abfrage über den aktuellen Stand durchgeführter 
Maßnahmen), das schnelle Beseitigen von Leistungsstörungen (Reaktions- und 
Wiederherstellungszeiten) und Eskalationsprozesse. 279 Notwendig ist außerdem 
eine 

• klare Abgrenzung der verschiedenen Service Levels (Leistungsspezifikation) 
und der Übergänge zwischen diesen. Für jeden Level ist eine Qualität oder ein 
Quantitätsstandard als messbare(r) Größe genau zu definieren. 

• Festlegung von Sanktionen (Vergütungsminderung bei kleinen, Vertragsstra- 
fen/pauschalierter Schadensersatz bei mittleren und fristlose Kündigung bei er- 
heblichen Abweichungen 280 ) bei Nichteinhaltung der für die jeweiligen SLs ge- 
schuldeten Leistungsmerkmale, z.B. Verfügbarkeiten. Die Sanktionen können 
entsprechend dem Maß der Abweichung gestaffelt werden, von der relativ klei- 
nen Vergütungsminderung über größere Vertragsstrafen bis zur fristlosen Kün- 
digung und/oder Schadensersatz. 

Weiter sind in SLAs zu regeln: 281 

• Termine, Fristen, z.B. für die Beseitigung kritischer Störungen. 

• Konditionen (Vergütungen, Vertragsstrafen, s.o.). 

• Nachweis der Leistungserbringung durch Messung (nachprüfbare Aufzeich- 
nungen über Art und Umfang der Leistungen). 

• Reporting des Anbieters in regelmäßigen Zeitabständen, inwieweit vereinbarte 
Leistungsmerkmale eingehalten worden sind. 282 

• Zulässige Ausreißerquote. 

• Einschwingphase (Anlaufzeit), in der SLA-Kriterien noch nicht anwendbar 
sind. 283 



279 Schneider/v.Westphalen/Peter, Software-Erstellungsverträge, G Rdn. 359, 372. 

280 Bräutigam , CR 2004, 248, 251; Braun , Die Zulässigkeit von Service Level Agreements, 
16; Hörl/Häuser, CR 2003, 713, 717; Schreibauerl Taraschka, CR 2003, 557, 561. 

281 Gadatsch, IT-Controlling, in: Tiemeyer (Hrg.), Handbuch IT-Management, 359, 374. 

282 Schreibauer/Taraschka, CR 2003, 557, 560. 

283 Gadatsch, IT-Controlling, in: Tiemeyer (Hrg.), Handbuch IT-Management, 359, 375. 
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Hinzukommen können 

• die Verpflichtung zur Auslieferung von Updates (in bestimmten zeitlichen 
Abständen), 

• zulässige Wartungsfenster, 

• Hotline, 

• Bonus-Regelung für besonders gute Einhaltung der Leistungspflichten . 284 

229 SLAs sehen vor, dass Störungsmitteilungen auf verschiedenen definierten Kom- 
petenzebenen (Service Levels) abgearbeitet bzw. je nach Störungsart und 
-komplexität auf die nächst höhere Ebene weitergereicht 285 und als Leistungen 
unterschiedlich abrechnet werden. Die Leistungen können etwa auf Netzwerke, 
Web-Hosting, Anwendungssoftware oder Kundenbetreuung/Help Desks bezogen 
sein . 286 In solchen SLAs muss transparent festgelegt sein, welche Levels angeboten 
und welche Leistungen auf welchem Level erbracht werden und unter welchen 
Voraussetzungen und in welcher Zeit spätestens für eine Störungsmeldung auf die 
nächsthöhere Stufe verwiesen wird. 

230 Für jeden Level sind also etwa Rahmenbedingungen der Serviceerbringung (Vor- 
aussetzungen, Ausnahmen), Servicequalität (Verfügbarkeit , 287 Zuverlässigkeit, 
Antwortzeiten zwischen Ein- und Ausgabe, Zeit für die Bearbeitung von Transak- 
tionen, etc.), Messmethodik (Häufigkeit, Methode, Verantwortung) und Repor- 
ting (Zeit, Art, Verantwortlichkeit) festzulegen 288 , ebenso Arbeits- und Bereit- 
schaftszeiten sowie Reaktionszeiten (von der Störungs-/Fehlermitteilung bis zum 
Beginn der Bearbeitung ) 289 und eine mittlere Zeitdauer für die Lösung von Benut- 
zerproblemen 290 bzw. zulässige Werte für ein Degrading des Service, für die Dauer 
von Datenübertragungen, die Übertragungsgeschwindigkeit, den Datendurch- 
satz/Zeiteinheit und die Antwortzeit zwischen Eingabe eines Zeichens und seine 
Wiedergabe auf dem Bildschirm oder die Dauer von Mängelbeseitigungen 291 zu 
definieren. Für den Kunden ist hierbei freilich letztlich nicht die Stufenfolge als 
solche entscheidend, sondern nur, ob und wann spätestens sowie unter welchem 



284 Schneider , CR 2004, 241, 246. 

285 Koch , Computer- Vertragsrecht Rdn.949. 

286 TowlelBruggeman , CRi 2002, 75, 76. 

287 „Verfügbarkeit“ wird definiert als Verhältnis der Zeit, in der der Dienst verfügbar war, 
zu der Zeit, in der der Dienst theoretisch hätte verfügbar sein können (Braun, Die Zu- 
lässigkeit von Service Level Agreements, 9). 

288 Blöse/Pechardscheck, CR 2002, 785, 787. 

289 Bei Reaktionszeiten ist zu differenzieren, ob die Reaktion im Bereich Hotline, User Help 
Desk, Support, etc. erfolgt ( HörllHäuser , CR 2003, 713, 715). 

290 Diekmann/ Pickert, Computerwoche 46/1991, 61, 62. 

291 TowlelBruggeman, CRi 2002, 75, 77. 
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Kostenaufwand er eine Problemlösung erwarten kann 292 . Da bisher kaum (jeden- 
falls veröffentlichte) Rechtsprechung existiert, bleibt zur Sicherung der V ertragser- 
füllung nur, die einzelnen Stufen möglichst klar und vollständig vertraglich zu 
definieren 293 , ebenso die geschuldeten maximalen Zeiten für die Störungsbeseiti- 
gung. 294 

Kunden können selbst Verfahren nutzen, um (im Rahmen eines sog. „User- 231 
orientierten Service-Level-Management“ (SLM)) die Verfügbarkeit zu kontrollie- 
ren: 295 

• Tracing des Netzverkehrs (sog. „Network X-Ray“), 

• Screen-Capture (Messung am Arbeitsplatz), 

• Record/Replay (Messung anhand definierter Workloads) und 

• Instrumentierung der Applikation mit Agenten 296 . 

Zu prüfen ist, ob und welche präventiven („proaktiven“) Kontrollen im System 232 
möglich sind, etwa laufendes Monitoring von Service Levels, automatische Infor- 
mationsübergabe an den Help Desk, Performance- und Verfügbarkeitsprognosen, 
automatische Fehlerkorrekturen etc. 297 

Festgelegt werden sollten auch die jeweils zu erfüllenden Mitwirkungsobliegen- 233 
heiten des Auftraggebers, so etwa bezüglich des Bereitstellens der Infrastruktur 
einschließlich Stromversorgung und Klimatisierung von Serverräumen, Zugangs- 
gewährung, Datensicherung. 298 



292 Koch, Computer- Vertragsrecht, Rdn. 950. 

293 Die Begrenzung auf Hardwarestörungen kann kontraproduktiv sein, wenn sich etwa im 
Vor-Ort-Einsatz herausstellt, dass ein Fehler durch Neuinstallation der Software be- 
hebbar ist ( Kihn , Computerwoche 17/2001, 64). 

294 Hier können Vertragstrafen zu vereinbaren sein, da in bis zu 40% aller Fälle Störungen 
nicht innerhalb der vertraglich festgelegten Zeiten beseitigt werden (Kihn, Computer- 
woche 17/2001, 64). 

295 Nach Wesseler, Computerwoche extra 5 v. 6.7.2001, 8, 9. Der Autor berichtet von einer 
Tagung den beherzigenswerten Satz: „Vereinbaren Sie nichts, was Sie nicht messen und 
verrechnen können“. 

296 Etwa im Rahmen der ARM(Application Response Measurementj-Standardisierung der 
CECMG (Central Europe Computer Measurement Group). 

297 Wesseler, Computerwoche extra 5, 6.7.2001, 8, 9. 

298 Börner! Buhl! Hellmich/Klettl Moos, Leitfaden IT-Recht, 57. 
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12. Software-Pflege in IT-Projekten 

a) Sicherung der fortlaufenden Nutzung von Software 

234 Um eine produktive Nutzbarkeit während der gesamten geplanten Nutzungsdauer 
zu sichern, sollte eine Pflegeverpflichtung des Anbieters bereits mit Abschluss des 
Vertrags über die Erstellung bzw. Überlassung der Software vereinbart werden. 
Der Beginn der Pflegeverpflichtung sollte mit dem Zeitpunkt der Abnahme zu- 
sammengelegt sein. Entstehen zwischen dem Beginn der produktiven Nutzung 
und dem Beginn der Pflegeverpflichtung zeitliche Lücken, kann die Software bzw. 
das gesamte IT-System in einen nichtdefinierten Zustand geraten, der zunächst 
gegen teilweise hohen Kostenaufwand zu untersuchen ist, bevor der Anbieter auf 
ihm Pflegeleistungen mit überschaubarem Leistungsrisiko aufsetzen kann. 

235 Bei längerfristiger Nutzung können für (Software-)Pflege bzw. (Hardware-)War- 
tung 299 erhebliche Kosten anfallen. Zutreffend wurde angemerkt, dass die Kosten 
für Wartung und Pflege während der vorgesehenen Nutzungsdauer in der Regel die 
Projektkosten um ein Vielfaches übersteigen. 300 Bei 20% jährlicher Wartungsgebühr 
bezahlt der Kunde z.B. die Software in fünf Jahren ein zweites Mal. 301 Eher ist des- 
halb zu prüfen, welche Leistungen tatsächlich benötigt werden. So ist eine Instand- 
setzungspflicht meist deutlich kostengünstiger als eine Instandhaltung; bei Instand- 
setzung muss nämlich nur ein Fehler nach seinem Auftreten mit einem geeigneten 
Mittel beseitigt (bzw. umgangen) werden (korrektive Maßnahmen). Bei Instandhal- 
tung muss der Anbieter hingegen verhindern, dass überhaupt ein Fehler auftritt, 
also präventive Maßnahmen ergreifen und laufend (also kostenaufwendig) kon- 
trollieren. 302 Auch sollten die Wartungsverträge auf der Grundlage des verhandel- 
ten Kaufpreises, nicht der des Listenpreises geschlossen und die Wartungsgebühren 



299 Der hier verwendete Sprachgebrauch hält sich an die von den BVB eingeführten Beg- 
riffsdefinitionen. In der Wirtschaftsinformatik wird aber der Begriff „Wartung“ eben- 
falls auf Software bezogen und als „die Anpassung an spätere Änderungswünsche der 
Anwender und an Veränderungen des Umfelds (Aufbauorganisation, Tarifverträge, 
Steuergesetze, Bilanzvorschriften usw.) sowie die Weiterentwicklung (im Sinne von 
Verbesserungen)“ definiert, „Pflege“ hingegen als „die Beseitigung von Fehlern, die im 
Laufe der Nutzung noch festgestellt werden“ {Stahlknecht/ Hasenkamp, Einführung in 
die Wirtschaftsinformatik, 214). Angesichts der unterschiedlichen Verwendungsweise 
der Begriffe empfiehlt sich unbedingt eine Begriffsdefinition im IT-Projektvertrag (bzw. 
im Systemvertrag). Dies gilt umso mehr, als beide Begriffe aus der Wirtschaftsinforma- 
tik Leistungen wie das Instandhalten umfassen. 

300 Streitz, IT-Projekte retten, 24. 

301 Niemann, Computerwoche 29/2003, 10. 

302 Für Softwarepflege s. etwa Schreibauerl Taraschka, CR 2003, 557, 559. 
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für mehrere Jahre festgeschrieben werden. 303 Die Vergütungspflicht sollte erst mit 
Beginn der produktiven Nutzung einsetzen, nicht schon mit Installation. 

Als rechtsmissbräuchlich wurde eine Kündigung des Pflegevertrags eingestuft, die 236 
erfolgte, um den Vertragspartner (Kunden) zur Zahlung einer Upgrade-Gebühr zu 
veranlassen. 304 

Die Mitteilung von Anbietern, die Weiterentwicklung und Pflege eines Produkts 237 
ab einem bestimmten Zeitpunkt einzustellen (,,End-of-Life“-Schreiben), stellt als 
solche noch keine Kündigung eines Software-Pflegevertrags dar. Vielmehr muss 
eine Kündigung gegenüber dem jeweiligen einzelnen Vertragspartner erfolgen. 

Eine bloße Notiz etwa auf einer Anbieter-Website ist nicht ausreichend. 305 

b) Service Level Agreements für Software-Pflege und andere Anbieterleistungen 

Weiter lassen sich auch die vom Anbieter einzuhaltenden Leistungsmerkmale 238 
abstufen. Dies geschieht in Service Level Agreements (SLAs). SLAs können auch 
die Pflege von Software regeln, ebenso die Wartung von Hardware, etwa Web- 
Serverrechnern, oder die Verfügbarkeitsmerkmale für Internet- Anbindungen. 

Im Rahmen von SLAs für Pflege bzw. Wartung lassen sich Störungsmitteilungen 239 
auf verschiedenen definierten Kompetenzebenen (Service Levels) abarbeiten bzw. 
je nach Störungsart und -komplexität auf die nächsthöhere Ebene weiterreichen 306 
und als Leistungen unterschiedlich abrechnen. Die Leistungen können etwa auf 
Netzwerke, Web-Hosting, Anwendungssoftware oder Kundenbetreuung/Help 
Desks bezogen sein. 307 



In solchen SLAs muss transparent festgelegt sein, welche Levels angeboten, wel- ^40 
che Leistungen auf welchem Level erbracht werden und unter welchen Voraus- 
setzungen und in welcher Zeit spätestens auf die nächsthöhere Stufe verwiesen 
wird. 



Die Leistung der Software-Pflege bzw. Systemwartung lässt sich mit verschiedenen 241 
technisch definierbaren Parametern näher spezifizieren. So bezeichnet man als 
„Reparaturzeit“ (Time To Repair, TTR) die Zeit bzw. die Summe der Zeiten zwi- 



303 Niemann, Computerwoche 29/2003, 10, 11. 

304 OLG Koblenz. Urt.v.27.5.1993 - 5 U 1938/92, CR 1993, 626. 

305 Näher zum End-of-Life-Schreiben s. Welker/ Schmidt, CR 2002, 873. 

306 Koch, Computer- Vertragsrecht, Rdn. 949. 

307 TowlelBruggeman, CRi 2002, 75, 76. 
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sehen Ausfall und Neuanlauf des Systems 308 . Die TTR ergibt sich aus der Summe 
der Diagnosezeit (Detection Time) und der Reparaturzeit. Meist wird eine mittlere 
Reparaturzeit zugrundegelegt (Mean Time To Repair, MTTR). Gemessen wird 
weiter die (mittlere) Zeit zwischen zwei Ausfällen ((Mean)Time Between Failures, 
MTBF) 309 . Für den Anwender ist die Vereinbarung der maximalen Dauer der TTR 
noch wesentlich wichtiger als die Mindestreaktionszeit, in der mit einer Fehlerbe- 
seitigung begonnen wird; dies gilt besonders, wenn die Anwendung unterbre- 
chungssensibel ist (etwa eine Webpräsenz) und jeder Nutzungsausfall zu einem 
Umsatzentgang führt. Werden Fehlerbehebungszeiten vereinbart, wird oft eine 
Unterscheidung nach Fehlerkategorien getroffen, z.B. in „critical“, „major“ und 
„minor“. 310 

242 Zur Sicherung der produktiven Nutzung können kombinierte Angaben erforder- 
lich sein, z.B. 99,86% Gesamtverfügbarkeit und zulässige absolute Downti- 
me/Monat. Teilweise wird zwischen „First-Line-Maintenance“ (die teilweise bei 
einfacher Fehlerbehebung sogar vom Kunden selbst durchzuführen sein kann) 
und Second/Third Line Maintenance durch den Anbieter/Lieferanten unterschie- 
den. 311 Liier empfiehlt sich naheliegenderweise eine möglichst genaue Abgrenzung, 
welche Maintenance-Positionen vom Kunden selbst zu erbringen sind. Wird der 
Kunde insoweit nicht tätig, kann dies die Leistungserbringung durch den Anbieter 
beeinträchtigen. 

c) Pflicht zur Software-Pflege während eines fünfjährigen „Life Cyde"? 

243 Der Anbieter von Pflegeleistungen ist nicht verpflichtet, Pflegeleistungen für den 
sog. „Life Cycle“ der Software am Markt vorzuhalten, also weit über die jeweilige 
Laufzeit bestehender Pflegeverträge hinaus. 312 Vereinzelt wurde eine weitergehen- 
de Pflegepflicht, nämlich während eines „Life Cycle“ von fünf Jahren, bejaht, 313 
jedoch werden sich diese Ansätze wohl nicht durchsetzen. „Life Cycle“ und Leis- 
tungspflichten aus Software-Pflegeverträgen sind nämlich schon begrifflich nicht 
deckungsgleich. 



308 Thurner/Dal Cinl Schneeweiß, Verläßlichkeitsbewertung komplexer Systeme, Informa- 
tik-Spektrum 21 (1998), 318, 319. 

309 Thurner/Dal Cinl Schneeweiß, a.a.O., 319. 

310 v. Baum, CR 2002, 705, 707. 

311 v. Baum, CR 2002, 705, 708. 

312 OLG Koblenz, Urt.v. 12.1.2005 - 1 U 1009/04, CR 2005, 482 (die Vertragswidrigkeit 
einer ordentlichen Kündigung verneinend und auf die individuelle Vereinbarung ab- 
stellend, nicht auf einen „Life Cycle“). 

313 LG Köln, Urt. v. 16.10.1997 - 83 O 26/97, CR 1999, 218 (eine Nebenpflicht aus § 242 
BGB annehmend); ähnlich schon OLG Koblenz, Urt.v. 27.5.1993 - 5 U 1938/92, 
CR 1994, 95. 
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„Life Cycle“ ist kein Rechtsbegriff, sondern ein solcher des Software-Engineering, 244 
muss also in dessen Zusammenhang verstanden und verwendet werden. Software- 
Entwicklung verläuft in verschiedenen, typischen Stufen, die nach ISO 12207 
meist als die Phasen Analyse, Entwurf, Codieren, Testen und Wartung unterschie- 
den und für die anbieterinterne Planung begrifflich als „Life Cycle“ 314 zusammen- 
gefasst werden. Dieser weitgehend anbieterinterne (und zudem applikationsspezi- 
fische) Lebenszyklus von Anwendungsprogrammen, 315 der im Software-Enginee- 
ring begrifflich Entwicklungszeit und Nutzungszeit umfasst, 316 lässt sich nicht für 
Kundenverträge pauschal als Pflicht zur Wartungsbereitschaft (und entsprechen- 
der Vertragsverlängerung) während fünf Jahren ab Installation oder gar ab letztem 
Inverkehrbringen (!) eines Produktexemplars der Software umdeuten, ab dem der 
Life Cycle erst beginnen soll, 317 während er tatsächlich auch den Zeitraum der 
internen Entwicklung umfasst. 318 Anbieter wären sonst für (bis zu) fünf Jahre 
verpflichtet, Pflegeleistungen anzubieten, also auch dann, wenn sie längst Folge- 
versionen vertreiben. Sie müssten deshalb die hierdurch anfallenden teilweise er- 



314 Die verschiedenen Phasen des Software-Life-Cycle werden in ISO 12207 näher darge- 
legt (nämlich die „primary processes“, also „acquisition, supply, development, mainte- 
nance and Operation“, und zugehörige „supporting processes“, nämlich „documentati- 
on, configuration management, quality assurance, verification, validation, joint review, 
audit, and problem resolution“ (s. www.acm.org/tsc/lifecycle.html)). 

315 Nach Koreimann, Grundlagen der Software-Entwicklung, 3.Aufl. 2000, 149, verursa- 
chen Analyse und Entwurf etwa 17% des Entwicklungsaufwands, das Codieren 8%, das 
Testen 25% und die Wartung 50%! Koreimann, a.a.O., 150, stellt fest: „Ein hoher War- 
tungsaufwand lässt den Schluss zu, dass die Qualitätsanforderungen nur mangelhaft be- 
rücksichtigt wurden, so dass Nachbesserungen auftreten. Ein hoher Aufwand für Testen 
bedeutet darüber hinaus, dass die Codierung unzureichend war, so dass die endgültige 
und fehlerfreie Codierung erst während der Testphase erfolgt. Die Ursache für unzurei- 
chende Programmqualität liegt in der Regel in einem mangelhaften Entwurf begründet. 
Es ist daher erforderlich, die Phasen des Lebenszyklus eines Projekts inhaltlich und 
formal so zu bestimmen, dass jede nachfolgende Phase keine Aktivitäten einer vorange- 
gangenen Phase mehr erfordert. Das bedeutet: Es ist - vom Engineering her - grundsätz- 
lich nicht erlaubt, beispielsweise in einer Phase „ Codierung “ Analyse und Design zu 
betreiben und es ist untersagt, in einer Phase „Testen und Integrieren“ nachträgliche Pro- 
grammierung und Programmfunktionen durchzuführen. Jede Phase muss inhaltlich so 
abgeschlossen sein, dass die nachfolgende Phase fehlerfrei realisiert werden kann“. Ein 
wichtiger Milestone müsse ein formelles Prüfverfahren bezüglich Qualität und Güte des 
Entwurfes (system design) sein, das durchgeführt wird, bevor die Freigabe zur Pro- 
grammierung erfolgt ( Koreimann , a.a.O., 152). 

316 Stahlknecht/ Hasenkamp, Einführung in die Wirtschaftsinformatik, 214; Balzert, Lehr- 
buch der Software-Rechnik - Software-Entwicklung, 1093, 1098. 

317 Koch, IT-Verträge: Wie man Fußangeln vermeidet, Computerwoche 1 1/2006, 42. 

318 Das OLG Koblenz, Urt.v.27.5.1993 - 5 U 1938/92, CR 1994, 95 datierte den „Life Cycle“ 
hingegen vom Beginn des Verkaufs bis zum letzten Käufer (freilich ohne nähere Be- 
gründung); ihm folgend etwa Kaufmann, CR 2005, 841, 843. Diese Auffassung ent- 
spricht nicht der Praxis in der Software-Industrie. 
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heblichen Mehrkosten in die Pflegevergütung „einpreisen“, was viele Kunden 
ohnehin zum Wechsel zur Folgeversion motivieren kann. Tatsächlich besteht 
ohne vertragliche Vereinbarung keine Verpflichtung, über bestehende Software- 
Pflegeverträge hinaus bestimmte qualifizierte Leistungen anzubieten. Gleiches gilt 
für die Verpflichtung, bestimmte Software-Releases für bestimmte zukünftige 
Zeiträume zu unterstützen. 

245 Eine Verpflichtung zum Abschluss bzw. zur Verlängerung von Wartungs-/ 
Pflegeverträgen zu marktüblichen Konditionen kann allerdings bestehen, wenn 
ein Anbieter eine marktbeherrschende Stellung hat, die Notwendigkeit für eine 
Wartung/Pflege besteht, kein anderer Anbieter eine vergleichbare Leistung anbie- 
tet und andere Kunden von diesem Anbieter derartige Wartungs-/Pflegeleis- 
tungen angeboten erhalten. Hier kann aus Kartellrecht ein Kontrahierungszwang 
zu bejahen sein (§ 20 GWB), 319 der aber z.B. nicht entsteht, wenn der Anbieter den 
anderen Kunden nur das neuere Folge-Release anbietet, und auch sonst eher auf 
Ausnahmefälle beschränkt ist. 320 

246 Bisher kaum rechtlich zugeordnet wurden Erklärungen von Anbietern zu der von 
ihnen verfolgten Roadmap, also zur Planung für neue Releases und Versionen in 
den Folgejahren. Mangels besonderer Erklärungen begründen solche Roadmaps in 
der Regel keine bindende Verpflichtung gegenüber gegenwärtigen oder zukünfti- 
gen Kunden. Wie die Praxis etwa mancher ERP-Softwareanbieter zeigt, werden 
langfristige Produktkonzepte nicht selten umgestoßen. 321 Die Verbindlichkeit von 
Roadmap -Erklärungen ist also keine (gar gefestigte) Praxis und kann deshalb nicht 
erwartet werden. Das muss dann freilich auch für Erklärungen gelten, bestimmte 
Produkte für die nächsten Jahre „stabil“ zu halten. Hier ist jeweils zusätzlich erfor- 
derlich, dass sich der Anbieter erkennbar verbindlich verpflichtet, laufende Soft- 
ware-Pflegeverträge für dieselbe Software zu marktüblichen Konditionen zu ver- 
längern. 

d) Instandsetzung und Instandhaltung 

247 Für die Festlegung des Leistungsumfanges wie für die Zuordnung zu einem Ver- 
tragstyp von besonderer Bedeutung ist die Unterscheidung zwischen den Leis- 
tungstypen „Instandhaltung“ und „Instandsetzung“ 322 . 

248 „Instandsetzung“ beinhaltet das Beseitigen mitgeteilter Fehler, allgemeiner das 
Wiederherstellen der Funktionsfähigkeit, und ist der Grundtyp der Pflegeleistung. 



319 Für alle s. Redeker, IT-Recht in der Praxis, Rdn. 674. 

320 Kaufmann, CR 2005, 841, 845. 

321 Niemann, SAP-Kunden fordern klare Roadmap, Computerwoche 39/2006, 6. 

322 S. näher Koch, Computer- Vertragsrecht Rdn. 959. 
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Bei vereinbarter Instandsetzung ist die Fehlerbeseitigung die geschuldete vertragli- 
che Hauptleistungspflicht (also nicht Nachbesserung) und eine Update-Lieferung 
eine Form zur Erfüllung dieser Pflicht. Eine Störung als solche ist - bei geschulde- 
ter Instandsetzung - kein Mangel der Wartungs- oder Pflegeleistung, sondern eine 
mögliche Folge eines Mangels dieser Leistung 323 bzw. generell der Auslöser für 
eine Leistungspflicht des Anbieters. Die Leistungspflicht wird erst mit kundensei- 
tiger Mitteilung eines zu beseitigenden Fehlers begründet. Gewährleistung aus der 
Instandsetzungspflicht tritt erst ein, wenn die Beseitigung unzureichend gelingt, 
nicht schon mit Auftreten des Fehlerzustandes als solchem. 

Findet der Kunde bei einer Funktionsprüfung des Updates die alten, bereits vor- 249 
handenen Fehler wieder, liegt im Rahmen vereinbarter Instandsetzung Nichterfül- 
lung vor, da die geschuldete Leistung (die Beseitigung eines fehlerhaften Pro- 
grammzustandes) nicht erbracht wurde. Entdeckt der Kunde hingegen neue 
Fehler im Update, liegt eine Pflichtverletzung gemäß den §§ 282, 241 Abs. 2 BGB 
vor, da der Kunde in seinen zukünftigen Programmnutzungsmöglichkeiten beein- 
trächtigt wird und einen frustrierten (bei Vertretenmüssen ersatzfähigen) Prüf- 
aufwand hat, der bei vertragsgemäßer Fehlerkorrektur nicht erforderlich gewor- 
den wäre. 

„Instandhaltung“ beinhaltet hingegen weit mehr als bloße Beseitigung gemeldeter 250 
Fehler, nämlich das Verhindern des Auftretens von Fehlern 324 . Maßstab ist bei 
Systemen oft eine Mindestverfügbarkeit 325 , bei Software eher unmittelbar die Feh- 
lerfreiheit des Nutzungslaufes. Hauptleistungspflicht ist hier die (manchmal „pro- 
aktiv“ genannte) Fehlervermeidung sowie ergänzend die Beseitigung trotzdem 
nicht vermiedener Fehler. Ein Mängelhaftungsfall tritt bereits ein, wenn ein Fehler 
trotz getroffener Vorkehrungen auftritt. Der Fehler zeigt, dass die präventionsori- 
entierte Leistung mangelhaft war oder, wenn man keinen Werkvertrag annimmt, 
jedenfalls eine Pflichtverletzung vorliegt. Die eigentliche Fehlerbeseitigung ist hier 
nicht Erfüllung, sondern Nachbesserung der geschuldeten Anbieterleistung (bzw. 
naturale Restitution des „Schadens“ aus der Schlechterfüllung). Eine Update- 
Lieferung folgt hier als Nachbesserungsleistung grundsätzlich Werkvertragsrecht. 
Zwischen Mitteilung der Mängelrüge bis zu tatsächlicher Update-Auslieferung 



323 OLG Hamm, Urt.v. 22.11.1988 - 31 U 63/88, CR 1989, 98. 

324 Koch, Computer- Vertragsrecht, Rdn. 970. Ein Beispiel ist die „proaktive“ Netzwerkun- 
terstützung mit Verfügbarkeitsanalysen und spezifischem Support sowie möglichem 
Remote-Updating von Software. 

325 Wohlgemuth, Computerwartung, 1999, 18. 
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nahm die Rechtsprechung Hemmung des Laufes der Verjährungsfrist an (entspre- 
chende Anwendung von § 639 Abs. 2 BGB 326 ). 

251 Instandhaltung kann durch Auslieferung einer neuesten Software-Version erfol- 
gen 327 (die der Kunde abzunehmen hat), sofern nicht Fehlerbehebung vor Ort 
vereinbart ist. Bestimmte maximale Lieferfristen bedürfen der Vereinbarung. Aus 
Pflegeverpflichtung schuldet der Anbieter grundsätzlich (mangels abweichender 
Vereinbarung) keine Lieferung von „Programmneuerungen“, also etwa höheren 
Programmlevels 328 oder sonstige geänderte oder zusätzliche Funktionalität, da sie 
die Funktionalität erweitern oder sonst verändern, während Software-Pflege 
grundsätzlich nur auf Erhaltung zielt. Kann der Anbieter die Instandhaltungsver- 
pflichtung nur durch Liefern eines entsprechend erweiterten Updates erfüllen, 
darf er keine Vergütung für die zusätzlichen Leistungsmerkmale verlangen. Füh- 
ren diese Merkmale dazu, dass das Programm mit der bisherigen Laufzeitumge- 
bung nicht mehr (voll) kompatibel ist und deshalb nur noch eingeschränkt oder 
überhaupt nicht mehr genutzt werden kann, muss der Kunde eine solche Version 
nicht abnehmen, sondern es liegt Nichterfüllung der geschuldeten Pflegeleistung 
vor. Der Kunde darf nicht vertraglich gezwungen werden, bei jeglicher Pro- 
grammänderung die Software erneut kostenpflichtig zu erwerben, um den Verlust 
seiner Geschäftsdaten zu vermeiden. Ein solcher Vertrag kann aufgrund knebeln- 
der Wirkung sittenwidrig und damit nichtig sein 329 . 

252 Soweit auf Pflegeleistungen Dienstvertragsrecht anzuwenden ist (weil etwa die 
Leistungen nach Weisung des Auftraggebers erbracht werden), kommt Schadens- 
ersatzhaftung wegen Pflichtverletzung in Betracht (§§ 280, 281, 628 Abs. 2 BGB). 330 

253 Back-Up-Leistungen können Teil der Datensicherung und, allgemeiner, der War- 
tung sein. Back-Up-Verträge wurden schwerpunktmäßig Werkvertragsrecht zu- 
geordnet. 331 Back-Up-Leistungen bedürfen besonderer Vereinbarung. 



326 Allgemein zur entsprechenden Anwendbarkeit s. etwa OLG Frankfurt, DB 1982, 2397 
(bei Vereinbarung der Nachbesserung) und BGH NJW 1984, 1252 bei verkäuferseitiger 
Mängeluntersuchung ohne besondere Vereinbarung. Mängelbeseitigung durch zeitlich 
unbestimmtes Updating führt also zur entsprechend längerfristigen Gewährleistungs- 
fristenhemmung. 

327 LG Köln, Urt. v. 11.5.1984 - 90 O 14/84, DV-R3, 234. 

328 LG Köln, Urt. v. 11.5.1984, a.a.O. 

329 AG Hanau, Urt.v.26.6.1998 - 31 C 709/98-11, JurPC Web-Dok.146/98 

330 Schreibauerl Taraschka, CR 2003, 557, 561. 

331 Schmid, CR 1994, 513, 518 
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e) Updates, Versionen, Upgrades 

Mängelbeseitigungen im Rahmen der Gewährleistung, Fehlerbeseitigung als Pfle- 254 
geleistung und kleinere Erweiterungen der Funktionalität werden von Anbietern 
meist als Updates ausgeliefert. Neue „Versionen“ enthalten hingegen (auch) we- 
sentlich neue Funktionsmerkmale, „Upgrades“ demgegenüber Programmanpas- 
sungen für leistungsstärkere Hardware oder Systeme. 

Fehlerbehebungen durch Updates erfolgen meist gegenüber der Gesamtheit der 255 
Kunden, damit die jeweilige Software- Version einheitlich bleibt und weiterge- 
pflegt werden kann. Das Software-Haus wurde als berechtigt angesehen, „tech- 
nisch vertretbare und gruppenverträgliche Entscheidungen“ zu treffen. 332 Dies 
bedeute, dass „die Nutzer nicht ohne Not alle paar Monate mit neuen Programm- 
ständen geplagt werden“. 333 Mangels weiterreichender Vertragsregelung dürfe der 
„Kunde nichts anderes als Pflege nach dem Stand der Technik verlangen“ und er 
müsse „im zumutbaren Umfang mit Softwarefehlern leben, Notlösungen akzeptie- 
ren und auf verbesserte Programmversionen warten, auch wenn das für ihn lästig 
oder nachteilig ist“. 334 Allerdings erscheint diese anbieternahe Auffassung eher auf 
Massensoftware zugeschnitten, nicht auf Software-Pflege für Unternehmen. 

Sofortige Fehlerbeseitigung darf der Kunde nicht erwarten, wenn der Pflegevertrag 256 
nur die Vereinbarung eines (zeitlich zudem oft nicht genau fixierten) Updating 
vorsieht. Mangels abweichender Vereinbarung stellt es dann eine vertragsgemäße 
Leistungserbringung dar, wenn der Anbieter einen mitgeteilten Fehler erst mit 
dem üblichen (zeitlich später) folgenden Update beseitigt; individuelle Fehler- 
korrektur (also unverzügliche Beseitigung des konkret gerügten Mangels) muss 
besonders vereinbart werden, ebenso die Beseitigung mitgeteilter Fehler innerhalb 
einer bestimmten Frist. 

Soweit Fehler unter einer laufenden Gewährleistung als Mängel zu werten sind, 257 
kann in dem Zeitraum zwischen Mitteilung und Behebung durch Update der Lauf 
der Verjährungsfrist gehemmt sein (§ 203 BGB). Rügt der Kunde (jedenfalls bei 
vereinbarter Instandsetzung) keine Fehler, so stellt die Nichtauslieferung von 
Updates (mangels besonderer Vereinbarung) während der Vertragslaufzeiten oder 
Teilen hiervon keine Nicht- oder Schlechterfüllung dar, solange der Anbieter aber 
eine qualifizierte Leistungsbereitschaft vorhält. 



332 Bartsch, NJW 2002, 1526, 1528 unter Verweis auf § 241 Abs. 2 BGB. 

333 Bartsch, a.a.O. für Fälle, in denen Installationen recht teuer sein können. Auch dürften 
Programmänderungen, die zu einer Änderung der Software-Umgebung führen (z.B. 
Hardware- Aufrüstung), nur im begründeten Einzelfall unter Abwägung dieses Nach- 
teils vorgenommen werden. 

334 Bartsch, NJW 2002, 1526, 1528. 
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258 Ob bzw. inwieweit der Anbieter Aktualisierungen der zu pflegenden Software 
schuldet, muss unter Berücksichtigung der jeweiligen Anwendung abgegrenzt 
werden. Der Anbieter muss grundsätzlich die Software nur auf einem technisch 
definierten, bereits bei Vertragsschluss bestehenden Nutzbarkeitsstatus halten 
(bzw. erhalten). Zu berücksichtigen sein können aber während der Vertragslauf- 
zeit auftretende voraussehbare Änderungen von Umgebungsbedingungen, etwa 
bei Änderung von Mehrwertsteuersätzen oder kassenärztlichen Abrechnungsfor- 
mularen oder einer Währungsumstellung 335 . Maßstab kann hier nur der vertrag- 
lich vorausgesetzte Gebrauch der Software (oder des Systems) sein, für die (bzw. 
das) die Pflegeleistungen erbracht werden. 

259 Upgrading von Software kann ein aufwendiges Projekt darstellen. Zu prüfen 336 
sind die tatsächlichen Kosten einschließlich Einweisungen bzw. Schulungen tau- 
sender Mitarbeiter des Kunden (bei Änderungen der Benutzeroberfläche, z.B. SAP 
GUI) und Mitwirkung bei der Installation, ebenso notwendige Anpassungen 
(Changes) der vorhandenen Anwendung durch Wegfall bisheriger individueller 
Ergänzungen bzw. Erweiterungen. Kostenfallen können auch längere Testphasen 
sein, ebenso die Übernahme der Daten und eine eingeschränkte Nutzung des 
bisherigen Release bis zum Beginn des Echtbetriebs („Going live“) des Upgrades. 
Die Durchführung des Migrationsprojekts muss in Phasen erfolgen, etwa von der 
Vorstudie zur Ist-Situation, Analyse der optimalen Migrationsstrategie mit Ein- 
binden bisher kundenindividueller Anpassungen und des neuen Release, Imple- 
mentierung, Integrationstest und Produktivstart . 337 Migrationsprojekte sind auch 
zwischen einander folgenden Releases möglich und sinnvoll . 338 

260 Aber auch das Weiternutzen des bisherigen Release kann risikobehaftet sein. Dies 
gilt etwa dann, wenn Änderungen am bisherigen Release vorgenommen werden, 
deren Auswirkungen nur mit Anbieterunterstützung beherrschbar sind. Friert 
man aber die Applikation ein, kann sich dies nachteilig auf die unterstützten Ge- 
schäftsprozesse auswirken, die sich nicht mehr flexibel anpassen lassen. Auch 
kann die Migration umso teurer werden, je länger gewartet wird, was im Einzelfall 
auf eine Neuinstallation hinauslaufen kann. 

f) Fehlerbeseitigungen 

261 Ein praxiswichtiges Leistungsmerkmal sind kurze Reaktionszeiten zwischen Feh- 
lermeldung und Eintreffen des Servicepersonals des Anbieters. Die Dauer dieser 



335 Euro-Umstellung war bei vermieteter Software geschuldet, wenn die neue Währung in 
der Vertragslaufzeit eingeführt wird (LG Wuppertal, Urt.v.28. 9.2001 - 11 O 94/01, CR 
2002, 7). 

336 S. die Übersicht in: Computerwoche 51/52 2002, 32. 

337 Kraus, Computerwoche 8/2005, 32. 

Ebert , Systematisches Requirements Management, 46. 
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Reaktionszeiten ist in der Regel von der jeweiligen Anwendung abhängig und 
bedarf entsprechender konkreter Vereinbarung. Dies gilt im Übrigen auch für 
Reparaturen, die nur gegen gesonderte Vergütung erbracht werden müssen. Das 
Serviceunternehmen darf hierbei seine Leistung nicht von einer vorhergehenden 
Erklärung des Kunden abhängig machen, die Kosten als zusätzliche zu überneh- 
men 339 . Die grundsätzlich als vertragliche Nebenpflicht einzustufende Einhaltung 
einer bestimmten Reaktionszeit, innerhalb deren mit der Leistung, also etwa mit 
der Störungsbeseitigung begonnen werden muss, kann bei besonderer Vereinba- 
rung selbst zur Hauptpflicht werden, so etwa, wenn der Nachweis ständiger Reak- 
tionsbereitschaft für den Kunden von wesentlicher Bedeutung ist (etwa bei dem 
Einsatz von software-gestützten Flugsicherungssystemen). Im Einzelfall ist zu 
prüfen, ob die Einhaltung durch Vereinbarung einer Vertragsstrafe bei Nichtein- 
haltung gesichert werden sollte. Auch bei vertragsgemäßer Erfüllung der Reakti- 
onspflicht ist aber noch keine rasche Beseitigung eines Fehlers gesichert. 

Nur schwierig vorab im Vertrag fixierbar ist die maximal zulässige Dauer der 262 
Fehlerbeseitigung, da die Fehlerursachen und erforderlichen Beseitigungsmaß- 
nahmen sehr unterschiedlich sein können. Vermeidbare Verzögerungen (etwa, 
weil Entwickler mit einem neuen Projekt beschäftigt sind), können Ersatzansprü- 
che aus Pflichtverletzung bzw. aus Verzug auslösen. Das generelle Festschreiben 
maximaler Fehlerbehebungsfristen in Kunden-AGB kann, jedenfalls dann, wenn 
Fehlerursachen und -auswirkungen (etwa bei Software Dritter) nicht vorhersehbar 
sind, nach § 307 Abs. 2 Nr. 1 BGB unwirksam sein, da dem Anbieter ein nicht 
kalkulierbares Leistungsrisiko aufgelastet würde. Zu prüfen ist hier aber, ob nicht 
im Einzelfall tatsächlich eigentlich zwischen den Vertragsparteien eine Instandhal- 
tungsverpflichtung vereinbart worden ist, bei der der Anbieter Vorkehrungen 
schuldet, dass Fehler gar nicht erst auftreten. Insoweit übernimmt der Anbieter 
auch das Risiko des Auftretens von Fehlern. Eine solche Vereinbarung eines Leis- 
tungsinhaltes unterliegt nach § 307 Abs. 3 S. 1 BGB nicht der AGB-rechtlichen 
Kontrolle. Das Werk „Wartung“ gilt bezüglich der Systeminstandhaltung als man- 
gelhaft, wenn die Anlage in einen Zustand gerät, in dem Störungen zu erwarten 
sind, und wenn dieser Zustand auf ungenügende Wartungs arbeiten zurückzufüh- 
ren ist 340 . Gleiches gilt für Software sinngemäß. 

Nicht nur bei der ursprünglichen Implementierung der Software, sondern auch 263 
bei erforderlichen Pflegemaßnahmen treffen den Kunden fallspezifisch unter- 
schiedliche Mitwirkungsobliegenheiten. Der Kunde hat grundsätzlich alle An- 
strengungen zu unternehmen, um eine reibungslose Pflege zu ermöglichen und 
alles zu unterlassen, was diese Maßnahmen erschweren oder unmöglich machen 



339 LG Heidelberg, Urt.v. 1.9.1986 - O 53/85 KfH I, IuR 1987, S. 108. 

OLG München, Urt.v.22.11.1988 - 25 U 5810/86, BB Beilage 10/1990, 9. 
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könnte 341 . So muss der Kunde etwa umgehend auftretende Störungen an (Hard- 
ware und) Software mitteilen, die aufgetretenen Fehler, soweit machbar, in einer 
für den Anbieter nachprüfbaren Form dokumentieren, dem Anbieter die zur 
Durchführung der erforderlichen Maßnahmen notwendige Zeit am System und 
Zugang zu diesem einräumen und bei der Leistungserbringung, soweit erforder- 
lich, selbst mitwirken (Vorführen der Fehler, Stellen von Personal etc.) 342 . 

264 Nicht abschließend geklärt ist, ob Software-Pflegeleistungen dokumentiert wer- 
den müssen. Für Leistungen zur Hardware-Wartung wird dies bei Fehlen einer 
entsprechenden Vereinbarung verneint 343 . Für Software -Pflege kann (und muss) 
das vereinbarungsunabhängige Bestehen einer Dokumentationspflicht jedenfalls 
dann bejaht werden, wenn Teile der Software weiterentwickelt werden. Insoweit 
ist wie bei Neuentwicklungen auch eine Dokumentation geschuldet. Aber auch für 
sonstige Leistungen zur Software-Pflege empfiehlt sich für den Anbieter schon aus 
Beweisgründen eine Dokumentation der erbrachten Leistungen. 

265 Jedenfalls sollte die entsprechende Dokumen tationsp flicht vertraglich als Teil 
geschuldeter Qualitätssicherung der Software-Pflegeleistung vereinbart werden. 
Da Fehlerbeseitigungs- und Entwicklungsarbeiten die Qualität der Software ver- 
schlechtern können, sind die durchzuführenden Programmänderungen auf ihre 
möglichen Auswirkungen auf andere Teile des Programmes (bzw. auf andere 
Komponenten des Systems) hin zu untersuchen. Diese und sonstige Maßnahmen 
der Qualitätssicherung sind auch für die Software-Pflege durchzuführen und zu 
dokumentieren. 

266 Die Vergütung für die Pflegeleistungen enthält zumeist zwei Komponenten, näm- 
lich eine Pauschale für regelmäßige Kontrollen und das sonstige Instandhalten der 
Anlage, und eine anlassbedingt berechnete Forderung aus Sonderkosten für Mate- 
rial und Anfahrt, Einsätze außerhalb der üblichen Geschäftszeit oder die Instand- 
setzung bei Fehlfunktionen, die vom Kunden zu vertreten sind. Die Pauschale für 
die Pflege wird auch dann fällig, wenn keine Leistung im jeweiligen Abrechnungs- 
zeitraum erforderlich war 344 bzw. der Kunde auf Wartungsleistungen verzichtet 
hat 345 . Werden Leistungen nicht in Anspruch genommen, kann also der Kunde 
keinen Erstattungsanspruch geltend machen, da das vertraglich geschuldete Werk 



341 Koch , Computer- Vertragsrecht Rdn. 970. 

342 Koch , Computer- Vertragsrecht Rdn. 970. 

343 OLG München, Urt.v. 24.4.1986 - 1 U 5742/85, CR 1988, 38. 

344 OLG Koblenz, Urt.v.17.2.1984 - 2 U 1286/82, IuR 1986, 363; OLG Karlsruhe, 
Urt.v.28.2.1985 - 9 U 102/83, CR 1987, 232; LG Hagen, Urt.v.26.4.1988 - 21 O 159/87, 
BB Beilage 15/1989, 8. 

AG Hamburg, Urt.v.4.10.1988 - 35 C 444/88, CR 1989, 1102f. 
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die Erhaltung des möglichst wenig störanfälligen Zustandes ist 346 bzw. das Vorhal- 
ten qualifizierter Leistungsbereitschaft 347 ist. 

g) Auf Software-Pflege anwendbares Recht, Mängelhaftung 

Leistungen aus Software-Pflegeverträgen folgen immer dann Werkvertragsrecht, 267 
wenn ein individuell definierter Leistungserfolg, etwa eine Lehlerbeseitigung oder 
eine (regelmäßige) Aktualisierung, geschuldet ist 348 , Dienstvertragsrecht hingegen, 
wenn eine qualifizierte Tätigkeit zu erbringen ist („best effort“ 349 ). Die Durchfüh- 
rung geschuldeter definierter Änderungen (Changes) unterliegt grundsätzlich 
Werkvertragsrecht 350 , ebenso diejenige von Ergänzungen oder Punktionserweite- 
rungen oder vom Portieren von Software auf andere Plattformen, das zumeist eine 
(weitgehend) eigenständige Entwicklung darstellt. Die Leistung ist auf einen ver- 
traglich definierten oder zumindest üblichen Status der Punktionsfähigkeit bezo- 
gen. Die Wahl der Mittel zur Erhaltung oder Wiederherstellung dieses Status steht 
dem Anbieter unter Werkvertragsrecht frei. Nimmt der Kunde vertragsgemäß die 
Kontrollen bzw. sonstigen entsprechenden Tätigkeiten selbst vor und unterstützt 
ihn das Software-Haus nur beratend, wird (insoweit) grundsätzlich nur Dienstver- 
tragsrecht anwendbar sein, ebenso ergänzend für das Vorhalten von Dienstleis- 
tungen über den gesamten Vertragszeitraum 351 . 

Auch Instandhaltung als Aufrechterhalten eines vertraglich definierten Status der 268 
Punktionsfähigkeit eines Programmes (oder Systems) ist ein (wenngleich auf einen 
Dauerzustand gerichteter) Erfolg im Sinne des Werkvertragsrechts, ebenso das 
Bereithalten qualifizierten, jederzeit einsatzbereiten Personals, da dieses Vorhalten 
zwingende Voraussetzung etwa für ein schnelles Wiederherstellen der Funktions- 
fähigkeit sein kann. Bei Software -Pflegeverträgen kann sich die Vertragsleistung 
auf das Vorhalten qualifizierter Leistung (Leistungsbereitschaft) reduzieren 352 . Der 
Charakter der Pflegeverpflichtung als Dauerschuldverhältnis steht der Anwen- 
dung von Werkvertragsrecht nicht entgegen. Der werkvertragliche „Erfolg“ wird 
hier, da der Vertrag für eine gewisse Laufzeit abgeschlossen wird, gewissermaßen 
zeitlich gestreckt und ist durch laufende Kontrolle herzustellen. Ein werkvertragli- 



346 AG Hamburg, Urt.v.4.10.1988 a.a.O. 

347 LG Berlin, Urt.v.22.5.2001 - 10 O 483/00, CR 2001, 743. 

348 LG Köln, Urt. v. 11.5.1984 - 90 O 14/84, DV-R 3, 234. 

349 Lejeune, K&R 2002, 441, 445. 

350 Hartmann/Thier, CR 1998, 581, 582. 

351 Für die Anwendbarkeit von Dienstvertragsrecht auf sorgfältig und regelmäßig zu 
erbringende Wartungsleistungen s. OLG Hamm, Urt.v. 22.11.1988 - 25 U 5810/86, CR 
1989, 283f. 

LG Hagen, Urt.v.26.4.1988 - 21 O 159/87, CR 1989, 814. 
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eher Erfolg muss nicht begriffsnotwendig als zeitlich punktuell zu erbringender 
verstanden werden 353 . 

269 Gerade bei Dauerschuldverhältnissen und zudem bei den für die EDV-Nutzung 
wesentlichen Kontroll- und Wartungsaufgaben setzt der Kunde besonderes Ver- 
trauen in die Person bestimmter Mitarbeiter des Anbieters und eine Übertragung 
der Leistungspflichten aus dem Wartungs vertrag auf Dritte (Subunternehmer) ist 
deshalb nur sehr eingeschränkt möglich, wenn der Kunde nicht zustimmt. Die 
Vereinbarung einer entsprechenden Übertragungsbefugnis in AGB wurde als 
unwirksam angesehen, wenn sie formularmäßig das Genehmigungserfordernis des 
§ 415 Abs. 1 BGB ersetzen soll 354 . 

270 Mangelhaft ist die werkvertragliche Wartungs-/Pflegeleistung, wenn die Anlage/ 
das System aufgrund der unzureichenden Arbeiten in einen störanfälligen Zustand 
gerät 355 ; das gilt auch für Software. Bei vereinbarter Instandhaltung (Erhalten eines 
definierten Status der Funktionsfähigkeit) stellt bereits das Auftreten eines Fehlers 
einen Leistungsmangel dar. Bei vereinbarter Instandsetzung löst der Fehler (nach 
seiner kundenseitigen Mitteilung) hingegen überhaupt erst die Leistungspflicht 
des Anbieters aus. Von Wartungs-/Pflegearbeiten zu unterscheiden sind Mängel- 
beseitigungsmaßnahmen, die im Rahmen der Mängelhaftung für die Erstel- 
lung/Überlassung der Software erbracht werden, kostenfrei zu erbringen sind 
(§§ 635 Abs. 2, 439 Abs. 2 BGB). 

h) Laufzeit von Software-Pflegeverträgen 

271 Die Vereinbarung eines auf unbestimmte Zeit geschlossenen Software-Pflege- 
vertrags mit einer Kündigungsfrist von drei Monaten zum Ablauf eines jeden 
Quartals verstößt nicht gegen § 309 Nr. 9 BGB. 356 Eine Verpflichtung zum Ange- 
bot von Pflegeleistungen für die Dauer von fünf Jahren ab dem letztmaligen An- 
gebot der Software am Markt („Lebenszyklus“) besteht nicht, da hier nicht an das 



353 So wurde etwa die (über einen Zeitraum geschuldete) Bauaufsicht werkvertraglich 
eingestuft (BGH NJW-RR 1998, 1027). Im EDV-Bereich kann das Erhalten oder Wie- 
derherstellen eines möglichst wenig störanfälligen Zustandes ein werkvertraglicher Er- 
folg sein (Palandt/Spraw, 63. Aufk, Einf.v. § 631, Rdn. 11 explizit „auch für Wartung 
über längere Zeit hinweg“), ebenso KG CR 1986, 772 (Computerwartungsverträge als 
Werkverträge mit Dauerwirkung); Müdler-Hengstenberg/Graf v. Westphalen, DV-Pro- 
jektrecht 1994, 128. 

354 OLG Bamberg, Urt. v. 1.10.1985 - 5 U 57/85, DV-R 3, 34 ff. 

355 OLG München, Urt.v.22.1 1.1988 - 25 U 5810/86, CR 1989, 283f, das die Beweislast für 
den Schaden (z.B. Head crash), die Pflichtverletzung und deren Kausalität dem Kunden 
zuordnet. 

356 OLG Koblenz, Urt.v. 12.1.2005 - 1 U 1009/04, CR 2005, 482 = MMR 2005, 472, die 
Anwendung des § 309 Nr. 9 BGB auf den kaufmännischen Geschäftsverkehr ablehnend. 
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konkrete Vertragsverhältnis angeknüpft wird, sondern an die Verfügbarkeit der 
Software am Markt. 357 

Der Kunde muss also zur Sicherung seiner Anwendung entweder einen Pflegever- 272 
trag mit einer Mindestdauer für die gesamte benötigte Nutzungszeit abschließen 
oder sich zumindest bei Vertragsabschluss im Vertrag die Leistungsbereitschaft 
des Pflegeanbieters für diese vorgesehene Nutzungszeit garantieren lassen. 

1 3. Regelungen zur Projektbeendigung 

a) Parallelbetrieb von alter und neuer Anwendung, Beendigungsunterstützung 

Oft laufen alte und neue Anwendung eine Zeitlang parallel. Dies ist etwa bei der 273 
Konvertierung von Altdaten auf das neue System der Fall, aber auch bei zunächst 
nur probeweiser Nutzung des neuen Systems bzw. der neuen Anwendung. Lizenz- 
rechtlich kann hier zu klären sein, ob die bisherige Software nicht nur zur produk- 
tiven Nutzung benutzt werden darf, sondern auch zu dem Zweck etwa einer Da- 
tenmigration auf andere Systeme. Nach dem Lizenzvertrag könnte hier der 
Bereich der zulässigen bestimmungsgemäßen Benutzung überschritten sein. 

Um diese Rechtsunsicherheit zu vermeiden, sollte der Anbieter im IT-Projekt- 274 
vertrag zur Beendigungsunterstützung verpflichtet werden. Hierzu gehört die 
Zustimmung zu Nutzungsläufen der Software zum Zweck der Migration zu ande- 
ren Systemen bzw. auf andere Plattformen, aber auch Herausgabe kundenseits 
benötigter spezifischer Datenformate und ausführbarer Programmteile (z.B. Klas- 
senbibliotheken) . 

b) Pflichten bei vertragsgemäßem Projektabschluss 

Soweit der Kunde Software nur zeitlich begrenzt nutzen können soll, ist zu regeln, 275 
ob der Kunde erhaltene Software-Exemplare auf Datenträger und selbst erstellte 
Kopien in seinem Rechner mit Ablauf der Vertragslaufzeit zurückgeben bzw. lö- 
schen soll. Eine Weitergabe an Dritte kann wirksam ausgeschlossen werden, auch 
im Formularvertrag. 

c) Pflichten bei Projektabbruch 

Auch bei Projektabbruch - etwa durch (jederzeit mögliche) Kündigung durch den 276 
Besteller (§ 649 BGB) oder Rücktritt (§§ 634 Nr. 3, 323, 326 Abs. 5 BGB) - beste- 
hen nachvertragliche Pflichten beider Vertragsparteien aus § 280 BGB, deren Um- 
fang nur im Einzelfall (notfalls unter Heranziehen von § 242 BGB) bestimmt wer- 



357 



OLG Koblenz, Urt.v. 12.1.2005 - 1 U 1009/04, CR 2005, 482, 483. Zum „Life Cycle“ s. 
oben Rdn. 243. 
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den kann. So muss der Anbieter Unterlagen und Datensicherungen zurückgeben, 
die er vom Kunden erhalten hat und die dieser weiterhin benötigt. Dritten darf der 
Anbieter dieses Material auch nachvertraglich nicht zugänglich machen. 

14. Qualitätssicherung der Anbieterleistung 

277 Der Anbieter muss seine IT-Projektleistungen qualitätsgesichert erbringen. Dies 
sollte im Projektvertrag ausdrücklich als Leistungsmerkmal vereinbart werden. 
Der Auftraggeber muss zunächst auch dann an Qualitätssicherung (QS) interes- 
siert sein, wenn die IT allein für seine (betrieblichen) Zwecke eingesetzt wird - 
allein schon, weil QS die Fehlerrückverfolgung erleichtert und beschleunigt. Das 
gilt aber erst recht, wenn der Auftraggeber die Projektleistung (z.B. eine erstellte 
Software) als Teil seiner eigenen Leistung wiederum seinen Kunden anbieten will 
und diesen selbst eine qualitätsgesicherte Leistung schuldet. Auch der Anbieter 
profitiert von Qualitätsmanagement, wie ein Merksatz plastisch verdeutlicht: 
„Qualität ist, wenn der Kunde und nicht das Produkt zurückkommt.“ 358 

278 DIN 66272 legt die folgenden, jeweils mit software-bezogenen Fragen verbunde- 
nen Qualitätsmerkmale fest: 359 

• Funktionalität: Sind alle im Pflichtenheft geforderten Funktionen vorhanden 
und ausführbar? 

• Zuverlässigkeit: Zu welchem Grad (z.B. in Prozent der Arbeitszeit bzw. der 
geforderten Nutzungszeit) erfüllt die Software dauerhaft die geforderten Funk- 
tionen (Verfügbarkeit)? Werden alle Funktionen richtig ausgeführt (Korrekt- 
heit)? 

• Benutzbarkeit (Benutzerfreundlichkeit): Wie schnell lässt sich der Umgang mit 
der Software vom Benutzer erlernen (Erlernbarkeit)? Wie einfach lässt sich die 
Software durch den Benutzer handhaben (Bedienbarkeit)? 

• Effizienz: Welches zeitliche Verhalten (Antwortzeiten im Dialogbetrieb, Lauf- 
zeiten im Stapelbetrieb) und welchen Ressourcenverbrauch zeigt die Software 
unter den gegebenen Systemvoraussetzungen (Hardware, Betriebssystem, 
Kommunikationseinrichtungen) ? 

• Änderbarkeit: Mit welchem Aufwand bzw. in welcher Zeit lassen sich Ände- 
rungen ausführen? Wie lässt sich der Aufwand für Fehlererkennung und 
-behebung minimieren (Wartbarkeit)? 

• Übertragbarkeit: Mit welchem Aufwand lässt sich die Software (insbesondere 
Standardsoftware) an individuelle betriebliche Anforderungen anpassen (An- 



358 HindellHörmannl Müllerl Schmied, Basiswissen Software-Projektmanagement, 138. 

359 Nach: Stahlknecht/ Hasenkamp, Einführung in die Wirtschaftsinformatik, 310. 
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passbarkeit)? Lässt sich die Software ohne großen Aufwand in anderen System- 
umgebungen zum Einsatz bringen (Portabilität)? Kann die Software bei Aus- 
tausch des Rechners (z.B. durch Übergang zu einem leistungsfähigeren Prozessor) 
unverändert eingesetzt werden (Skalierbarkeitbzw. Aufwärtskompatibilität)? 

Die Qualitätssicherung von Anbieterleistungen und der Nachweis durch Zertifizie- 279 
rung werden heute durchweg von der öffentlichen Hand bei der Projektausschrei- 
bung vorausgesetzt. Mit weniger sollten sich auch andere Auftraggeber/Kunden 
nicht zufriedengeben. 

Qualitätssicherung garantiert allerdings nicht absolute Mängel- oder Wartungs-/ 280 
Pflegefreiheit oder unbegrenzte Lebensdauer, sondern legt nur bestimmte Mindest- 
standards und V erfahren fest, die nicht immer alle im konkreten Anwendungsfall 
relevanten Aspekte werden abdecken können. Die Qualitätssicherung der Leistung 
kann schon als solche ein wesentliches wertbildendes Leistungsmerkmal darstellen, 
das für die weitere V erwendbarkeit der Leistung von Bedeutung ist, so etwa, wenn der 
bestellende Kunde die Leistung selbst in einem eigenen Produkt an seinen Abnehmer 
weitervertreibt, der aus Vertrag die Qualitätssicherung des Gesamtproduktes ver- 
langt. ln diesem Fall stellt das Fehlen der Qualitätssicherung einen Leistungsmangel 
dar, der Gewährleistungsrechte begründen kann. 

Freilich reicht es nicht aus, im IT-Projektvertrag einfach nur die Pflicht des Anbie- 281 
ters zur Qualitätssicherung zu vereinbaren. Vielmehr ist zu unterscheiden: Das 
Einrichten und Anwenden eines Qualitätsmanagementsystems folgt dem formalen 
Modell der EN/ISO 9000, 9001 und 9004. Man spricht hier von „Prozessnormen“, 
da in ihnen der Ablauf der Qualitätssicherung beschrieben wird. Spezifisch für 
bestimmte Komponenten wie Software müssen aber ergänzend inhaltlich orien- 
tierte Normen herangezogen und vereinbart werden („Produktnormen“). 



Qualitätssicherung in IT-Projekten wird meist nur dann zum Erfolg führen, 282 
wenn sie parallel zur Entwicklung der Software durchgeführt und spätestens 
beim Erreichen des Ziels der jeweiligen Phasen (Milestones) kontrolliert wird - 
und zwar auch vom Auftraggeber. Im Software-Engineering selbst wird verlangt, 
dass am Ende jeder Phase die Qualität des entstandenen Zwischenprodukts mit 
analytischen Mitteln beurteilt werden muss (integrierte Qualitätssicherung). 360 
Ein Zwischenprodukt, dessen Qualität unzureichend ist, darf hiernach solange 
nicht in die folgende Phase weitergereicht werden, bis eine definierte, aus- 
reichende Qualität erreicht ist. 361 Dieses Vorgehen kann der Auftraggeber auch 
aus dem IT-Projektvertrag vom Anbieter beanspruchen. Ein solches Vorgehen 



360 Liggesmeyer, Software-Qualität, 2. 

361 Liggesmeyer, Software-Qualität, a.a.O. 
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stufenweiser Kontrollen muss freilich aus Auftraggebersicht vertraglich abgesi- 
chert, der Auftraggeber also berechtigt sein, bei Verfehlen eines Qualitätsziels 
dem Übergang zur nächsten Phase seine Zustimmung zu versagen und dies 
durch Zurückbehalten einer bei Zielerreichung fälligen Teilvergütung zu un- 
terstreichen, ohne mit seiner Mitwirkung in Verzug zu geraten. 



283 Diese Kopplung von qualitätsgesicherter Entwicklung und Vertragserfüllung 
stärkt die vertragliche Position des Auftraggebers und ist auch inhaltlich sinnvoll: 
Ein solches gestuftes Vorgehen hilft, möglichst viele Fehler bereits in der Prüfung 
zu erkennen, die auf den Konstruktionsschritt folgt, in dem der Fehler entstanden 
ist; dies hilft, Qualitätsabweichungen frühzeitig zu erkennen und Maßnahmen zu 
ihrer Beseitigung zu ergreifen. 362 

284 Auftraggeber dürfen die Qualitätssicherung von IT-Leistungen (und ein sie steu- 
erndes anbieterseitiges Qualitätsmanagement) berechtigterweise und unabhängig 
von einer besonderen Vereinbarung als Standard bzw. Stand der Technik erwar- 
ten. Der Anbieter muss, auch wenn er von Prüfinstanzen (noch) nicht zertifiziert 
wurde, im Rahmen seiner Vertragserfüllung geeignete QS-Verfahren und -metho- 
den einführen und anwenden. Um hier ein geregeltes Vorgehen sicherzustellen, 
muss der Anbieter ein Qualitätsmanagementsystem implementieren und ergän- 
zend inhaltliche Normen insbesondere bei der Entwicklung von Software beach- 
ten. Rein vorsorglich kann aber nur dringend empfohlen werden, die QS aller 
Anbieterleistungen im Vertrag ausdrücklich als vereinbarte Beschaffenheit (im 
Sinne von § 633 Abs. 2 S. 1 BGB) festzuschreiben. Eine solche Bestimmung wird 
auch in Einkaufs-AGB nicht als unangemessen (i.S.v. § 307 BGB) anzusehen sein. 

285 Die Nichteinhaltung von DIN-/ISO-Normen kann zu Leistungsabweichungen 
führen, die als Mängel zu beurteilen sind. Sie kann außerdem bereits als solche ein 
Indiz für die Verletzung einer Verkehrssicherungspflicht des Elerstellers darstel- 
len 363 . Außerdem kann in ihr die Verletzung einer vereinbarten Beschaffenheit zu 
sehen sein, wenn die Normeinhaltung als Beschaffenheit ausdrücklich garantiert 
war, der Anbieter also ausdrücklich oder zumindest deutlich erkennbar von den 
Sachverhaltsumständen her für die folgende Nichteinhaltung der QM-Normen 
einstehen will oder zumindest die spezifischen technischen Daten des Produkts 
und diejenigen seiner Herstellung eine - für den beauftragten Lieferanten erkenn- 
bar - überragende Bedeutung für den bestellenden Kunden besitzen und der Ver- 
trag vom Kunden in dem Falle nicht geschlossen worden wäre, dass die techni- 
schen Vereinbarungen nicht zuverlässig eingehalten werden. 



362 Liggesmeyer, Software-Qualität, 3. 

363 Grafv. Westphalen, Qualitätssicherung, Rdn. 32 
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DIN-Vorschriften sind allgemein anerkannte Regeln der Technik 364 und damit 286 
Teil der Vorgaben für Qualitätssicherungsverfahren, deren Einhaltung grundsätz- 
lich keiner besonderen Vereinbarung bedarf. Gleiches gilt für EN/ISO-Normen 
sinngemäß. Die Nichteinhaltung von DIN/EN/ISO-Normen kann zu Leistungs- 
abweichungen führen, die gewährleistungsrechtlich als Mangel zu beurteilen sind, 
so etwa, wenn die zugelieferte, nicht (ausreichend) qualitätsgesicherte Leistung 
vom bestellenden Kunden deshalb nicht weiter an seine Abnehmer veräußert 
werden kann (ohne dass ein inhaltlicher Fehler vorliegen muss). Auch kann die 
Nichteinhaltung der Norm als solche bereits ein Indiz für die Verletzung einer 
Verkehrssicherungspflicht des Anbieters/Elerstellers darstellen. 365 

Die Qualitätssicherung muss, wenn sie Sinn machen soll, alle Leistungen des An- 287 
bieters erfassen, also insbesondere auch Wartung, Pflege, Mängelbeseitigung (bug 
fixes!), Weiterentwicklung, Schulung, etc. Fehlende Qualitätssicherung auch nur 
einer Leistungskomponente kann das gesamte Projekt in Frage stellen. Wird auch 
nur eine Stufe übersehen, kann nämlich die ganze Qualitätssicherungs“kette“ 
reißen. 

Qualitätssicherung muss also parallel zum Projektverlauf durchgeführt, dokumen- 288 

tiert und nachgewiesen werden. Sie ist deshalb Hauptleistungspflicht des Anbie- 
ters im IT-Projekt. Zumindest beim Erreichen der jeweiligen Milestones muss der 
Auftraggeber prüfen (können), ob die für die jeweilige Stufe erforderlichen QS- 
Maßnahmen durchgeführt und dokumentiert wurden. Der Auftragnehmer muss 
das Erreichen der jeweiligen Phasenziele darlegen (und im Rechtsstreit beweisen 
können). Dies muss insbesondere durch Verfügbarmachen dokumentierter Test- 
ergebnisse erfolgen. Der Auftragnehmer muss hierbei nichts anderes tun als zu 
dokumentieren, dass er die jeweils geschuldete (Teil-) Leistung vereinbarungsge- 
mäß erbracht hat. 

Den Anbieter trifft jeweils die volle Haftung für die Organisation der Qualitätssi- 289 
cherung in seinem Leistungsbereich (und dem seiner Erfüllungsgehilfen). Unter- 
lässt der Anbieter die erforderliche Qualitätssicherung, richtet er insbesondere 
nicht die zur Durchführung und Kontrolle der Qualitätssicherung notwendige 
Organisation des Herstellungsprozesses ein, haftet er für diesen Organisationsfeh- 
ler. Der Kunde ist dann rechtlich so zu stellen, als wäre der Mangel dem Unter- 
nehmen bei Ablieferung des Werkes bekannt gewesen. 366 Die Norm DIN/ISO 
9004:2000, Nr. 5 legt in Übereinstimmung mit den allgemeinen Grundsätzen aus- 
drücklich die Verantwortlichkeit der obersten Leitung für Festlegen der Quali- 



364 BGH, Urt. v. 6.6.1991 - I ZR 234/91, BB 1991, 817. 

365 Grafv. Westphalen, Qualitätssicherung, Rdn. 32. 

BGH, Urt. v. 12.3.1992 - VII ZR 5/91, ZIP 1992, 773, 774. 
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tätspolitik und für Entscheidungen zur Einführung, Entwicklung, Verwirklichung 
und Aufrechterhaltung des Qualitätssicherungssystems fest. Fehler in oder Unter- 
lassen der erforderlichen Qualitätssicherungsorganisation stellen damit grundsätz- 
lich auch eine Verletzung von DIN/ISO-Normen und damit in der Regel bereits 
hierdurch eine Vertragsverletzung dar. 

290 Nach Auffassung des BGH (und in Übereinstimmung mit der genannten Norm) 
kann sich der Unternehmer (Anbieter) seiner vertraglichen Organisationspflicht 
nicht dadurch entziehen, dass er sich unwissend hält oder sich keiner Gehilfen bei 
der Pflicht bedient, Mängel zu offenbaren. 367 Der Unternehmer haftet, wenn er die 
Überwachung und Prüfung des Werkes nicht oder nicht richtig organisiert hat 
und der Mangel bei richtiger Organisation entdeckt worden wäre. Der Besteller 
(Kunde) sei dann so zu stellen, als wäre der Mangel dem Unternehmer bei Abliefe- 
rung des Werkes bekannt gewesen. 368 Verjährung der Kundenansprüche tritt nach 
drei Jahren ein (§ 195 BGB), für Schadensersatzansprüche aus Verletzung des 
Lebens, des Körpers, der Gesundheit oder der Freiheit jedoch erst nach dreißig 
Jahren (§ 199 Abs. 2 BGB)! 

Jedes IT-Projekt ist immer auch ein QS-Projekt und als solches kundenseits zu 
kontrollieren. Deshalb werden nachfolgend die prägenden Elemente der QS knapp 
rekapituliert. 

a) Qualitätsmanagement - zentrale Begriffe und Anbieterpflichten 

29 1 „Qualität“ ist definiert als „die Gesamtheit von Eigenschaften und Merkmalen eines 
Produktes oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung festgelegter 
und vorausgesetzter Erfordernisse bezieht“ (DIN 55 350/11), 369 nach Norm EN ISO 
9000:2005 Nr. 3.1.1 hingegen als der „Grad, in dem ein Satz inhärenter Merkmale 
Anforderungen erfüllt“. Beispiele für Qualitätseigenschaften sind etwa Sicherheit, 
Zuverlässigkeit, Verfügbarkeit, Robustheit, Speicher- und Laufzeiteffizienz, Ander - 



367 Der BGH stellt ausdrücklich fest: „Sorgt er bei der Herstellung des Werkes nicht für 
eine den Umständen nach angemessene Überwachung und Prüfung der Leistung und 
damit auch nicht dafür, dass er oder seine insoweit eingesetzten Erfüllungsgehilfen et- 
waige Mängel erkennen können, so handelt er vertragswidrig. Er ist gehalten, den 
Herstellungsprozeß zu überwachen und das Werk vor Abnahme zu prüfen. Denn der 
Unternehmer muss fehlerfrei leisten. Er muss daher jedenfalls die organisatorischen 
Voraussetzungen schaffen, um sachgerecht beurteilen zu können, ob das festgestellte 
Werk bei Ablieferung keinen Fehler aufweist“, BGH, Urt. v. 12.3.1992 - VII ZR 5/91, 
ZIP 1992, 773, 774. 

368 BGH, a.a.0„ 774. 

369 Ähnlich DIN 8402: ... „Gesamtheit von Merkmalen (und Merkmalswerten) einer Ein- 
heit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen.“ 
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barkeit, Portierbarkeit, Prüfbarkeit und Benutzbarkeit. 370 Diese Merkmale lassen sich 
nicht in jedem Fall einfach zu einem Gesamtprodukt quasi addieren, sondern können 
im Einzelfall sogar konfligieren. Um ein System sicher zu gestalten, kann es etwa 
erforderlich sein, dass durch Redundanz Komponentenausfälle erkannt werden 
können und das System in einen sicheren Zustand übergehen kann; dies kann aber 
dazu führen, dass ein derartiges System geringere Verfügbarkeit aufweist. 371 Auch 
wird zu wählen sein, ob die Speichereffizienz (möglichst geringer Speicherbedarf) 
oder die Laufzeiteffizienz (geringstmögliche Laufzeit) optimiert werden soll. 372 

„Fehler“ definiert DIN/ISO 8402 als „Nichterfüllung einer festgelegten Forde- 292 
rung“, bei Software die statisch im Programmcode vorhandene Ursache eines 
Fehlverhaltens oder Ausfall. 373 

Der übergreifende Begriff „Qualitätsmanagement“ (QM, definiert in den Normen 293 
EN ISO 9000:2005 Nr. 3.2.6) bezeichnet „aufeinander abgestimmte Tätigkeiten 
zum Leiten und Lenken einer Organisation“ bezüglich Qualität. 374 ISO 8402 defi- 
niert QM als „alle Tätigkeiten der Gesamtführungsaufgabe, welche die Qualitäts- 
politik, Ziele und Verantwortungen festlegen sowie diese durch Mittel wie Quali- 
tätsplanung, Qualitätslenkung, Qualitätssicherung und Qualitätsverbesserung im 
Rahmen des Qualitätsmanagementsystems verwirklichen.“ 

Ein QM-System ist nach ISO 8402 definiert als „die Organisationsstruktur, Verant- 294 
Wörtlichkeiten, Prozesse und erforderlichen Mittel für die Verwirklichung des Qua- 
litätsmanagements“, noch formaler nach EN ISO 9000:2000 Nr. 3.2.3 als ein Mana- 
gementsystem zum Leiten und Lenken einer Organisation bezüglich der Qualität. 
Qualität darf nicht nur geprüft, sondern muss auch geplant und gesteuert werden. 

Dies kann zu erheblichen Einsparungen bei den Kosten für Tests, aus Kundenan- 
sprüchen, Problemverwaltung, Verteilung und Installation von Korrekturen, etc. 
führen. Man spricht deshalb nicht mehr von „Qualitätssicherung“ (im Sinne einer 
nachträglichen Prüfung), sondern von „Qualitätsmanagement“, das als laufender 
Prozess parallel zur Produktion bzw. Dienstleistungserbringung durchgeführt wird. 



370 Liggesmeyer, Software-Qualität, 6. 

371 Liggesmeyer, Software-Qualität, 6. 

372 Liggesmeyer, Software-Qualität, 6. 

373 Liggesmeyer, Software-Qualität, 7. 

374 Hierzu gehören nach der Anmerkung zu Nr. 3.2.8 das Festlegen der Qualitätspolitik 
und der Qualitätsziele, die Qualitätsplanung und -lenkung, die Qualitätssicherung und 
die Qualitätsverbesserung. Hierdurch wird ISO 8402 eng mit EN/ISO 9000:2005 
Nr. 3.2.6 verknüpft. 
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295 Der Anbieter muss ein QM-System einrichten, d.h. aufbauen, dokumentieren, ver- 
wirklichen, aufrechterhalten und dessen Wirksamkeit ständig verbessern (EN/ISO 
9001:2000 Nr. 4.1). Die Organisation (d.h. das Unternehmen) muss 

a) die für das QM-System erforderlichen Prozesse und ihre Anwendung in der 
gesamten Organisation erkennen, 

b) die Abfolge und Wechselwirkung dieser Prozesse festlegen, 

c) die erforderlichen Kriterien und Methoden festlegen, um das wirksame Durch- 
führen und Lenken dieser Prozesse sicherzustellen, 

d) die Verfügbarkeit von Ressourcen und Informationen sicherstellen, die zur 
Durchführung und Überwachung dieser Prozesse benötigt werden, 

e) diese Prozesse überwachen, messen und analysieren, und 

f) die erforderlichen Maßnahmen treffen, um die geplanten Ergebnisse sowie eine 
ständige Verbesserung dieser Prozesse zu erreichen (EN/ISO 9001:2000 Nr. 4.1). 

296 Nach EN/ISO 9004:2000 Nr. 4.1 sollte die „oberste Leitung“ eine kundenorientier- 
te Organisation aufbauen, indem sie 

a) Systeme und Prozesse festlegt, die klar verstanden, geleitet, gelenkt und in ihrer 
Wirksamkeit und Effizienz verbessert werden können, und 

b) den wirksamen und effizienten Ablauf und die Lenkung der Prozesse, Maß- 
nahmen und Daten, die zum Erkennen einer zufriedenstellenden Leistung der 
Organisation verwendet werden, sicherstellt. 

297 DIN/ISO 9000:2005 Nr.3.2.11 bezeichnet „Qualitätssicherung“ (QS) als Teil des 
QM, der auf das Erzeugen von Vertrauen darauf gerichtet ist, dass Qualitätsanfor- 
derungen erfüllt werden. Qualitätssicherung bezeichnet vor allem die Darlegung 
des QM-Systems (DIN 55350-11/ DIN EN ISO 8402:1995-08). Das Dokumentie- 
ren der richtigen und vollständigen Erbringung von Arbeitsleistungen der Mitar- 
beiter ist damit zentraler Teil der marktüblichen Qualitätssicherung und zugleich 
der Erfüllung der Vertragspflichten des Anbieters. 

298 Die Auswahl der jeweils geeigneten Qualitätssicherungsverfahren beurteilt sich 
nach den sechs Faktoren Komplexität des Design- und des Realisierungsprozesses, 
Designreife, den Merkmalen und der Sicherheit des Produkts oder der Dienstleis- 
tung sowie der Wirtschaftlichkeit. Qualitätssicherung kann nicht statisch erfolgen, 
sondern erfordert laufende Kontrollen während des Herstellungsprozesses. Erst 
nach dessen Ende erfolgende Kontrollen sind zumeist nur eingeschränkt möglich. 
Notwendige Qualitätskontrollen verfolgen im Bereich des Software-Engineering 
sieben Aufgaben, nämlich die 

• Akzeptanz der Anforderungen, 

• Abnahme der Spezifikation (der Problemlösung), 
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• Bewertung des Entwurfs (Design Review), 

• Prüfung von Programmen (Code-Inspection) und von Dokumenten, 

• Programmtestrevision (Test-Audition), 

• Systemtestrevision und 

• Systemabnahme. 375 

b) Einrichten und Aufrechterhalten eines Qualitätsmanagementsystems 
als Vertragspflicht des Anbieters 

Der Lieferant muss ein dokumentiertes Qualitätsmanagementsystem als Mittel zur 299 
Sicherstellung der Erfüllung der festgelegten Qualitätsforderung durch das Pro- 
dukt einrichten und aufrechterhalten. Es muss einschließen: die Ausarbeitung 
dokumentierter Verfahren und Anweisungen bezüglich des Qualitätsmanage- 
mentsystems in Übereinstimmung mit den Forderungen dieser internationalen 
Norm (EN/ISO 9001:2000), ebenso die effektive Verwirklichung dokumentierter 
Verfahren und Anweisungen im Qualitätsmanagementsystem. 

Das QM-System besteht inhaltlich aus der Aufbauorganisation, den Verantwort- 300 
lichkeiten, Abläufen, Verfahren und Mitteln zur Verwirklichung des Qualitätsma- 
nagements als Führungsaufgabe, das die umfassenden qualitätsbezogenen Absich- 
ten und Zielsetzungen des Unternehmens festlegt und verwirklicht. Das von der 
Unternehmensleitung zu entwickelnde, festzulegende und zu verwirklichende 
Qualitätssicherungssystem soll entsprechend der besonderen Art der Geschäftstä- 
tigkeit des Unternehmens strukturiert und ihr angepasst sein und dabei die in der 
Norm geschilderten geeigneten Elemente in Betracht ziehen (vgl. näher EN/ISO 
9004 Nr. 4.1). Die Funktionsauslegung des Qualitätssicherungssystems soll volles 
Vertrauen schaffen, dass 

a) das System gut verstanden wird und wirksam ist, 

b) die Produkte oder Dienstleistungen die Erwartungen der Kunden erfüllen und 

c) das Hauptaugenmerk viel mehr auf die Vermeidung von Problemen gelegt 
wird, als sich auf ihre Entdeckung nach dem Auftreten zu verlassen. 

Das QM-System soll alle Phasen im sog. Qualitätskreis erfassen wie Marketing 301 
und Marktforschung, Design/Spezifizierung und Entwicklung des Produkts, Be- 
schaffung, Prozessplanung und -entwicklung, Produktion, (Qualitäts-)Prüfungen 
und Untersuchungen, Verpackung und Lagerung, Verkauf und Verteilung, Mon- 
tage und Betrieb, technische Unterstützung und Instandhaltung, Beseitigung nach 
dem Gebrauch. Hierzu wird das Modell eines prozessorientierten QS-Manage- 
mentsystems verwendet (s. näher EN/ISO 9004:2000, Nr. 0.2). Alle qualitätsbeein- 



375 



Sneed , Software-Qualitätssicherung für kommerzielle Anwendungssysteme, 28. 
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flussenden Tätigkeiten sollten angemessen und dauernd gelenkt werden (s. näher 
EN/ISO 9004:2000 Ziff. 4.1). 

302 In den Normen DIN/ISO 9001 und 9004 sind die unterschiedlichen nationalen, 
auf Qualitätsmanagement bezogenen Forderungen an Produkte und Dienstleis- 
tungen vereinheitlicht worden. Die Normen ISO 14001, 14004 enthalten Anforde- 
rungen an ein umweltbezogenes Managementsystem für Produktion. Die nachfol- 
gend näher darzustellenden Grundsätze gelten hier entsprechend. 

303 Gerade auch bei Software muss die Sicherung der Qualität in ihrem Prozesscha- 
rakter verstanden werden, nämlich als ein Hineinentwickeln notwendiger Quali- 
tätsmerkmale in das Produkt, das nicht erst nachträglich, sondern nur während 
der Produktentwicklung selbst erfolgen kann. Außerdem muss ein umgebender 
Rahmen von Prüfungen, Kontrollen und Nachweisen sichergestellt werden 376 . 
Beide Komponenten sind in den Grundnormen der Qualitätssicherung EN/ISO 
9000:2005, 9001:2000 und 9004:2000 näher festgelegt. 

c) Auditierung von Qualitätsmanagementsystemen 

304 Die Geschäftsleitung des Anbieters muss in regelmäßigen Abständen interne Au- 
dits 377 durchführen, um zu ermitteln, ob das QM-System die aus Normen und 
Festlegungen der Geschäftsleitung folgenden Anforderungen erfüllt sowie wirk- 
sam verwirklicht und aufrechterhält (EN/ISO 9001:2000 Nr. 8.2.2 Abs. 1). Hierzu 
müssen die Auditkriterien, der Auditumfang, die Audithäufigkeit und die Audit- 
methoden festgelegt und die Verfahren dokumentiert werden. Auditorenauswahl 
und Auditdurchführung müssen objektiv und unparteilich erfolgen. Auditoren 
dürfen ihre eigene Tätigkeit nicht auditieren (EN/ISO 9001:2000 Nr. 8.2.2 Abs. 2). 

305 Durch Vereinbarung kann der Kunde berechtigt sein, eigene QS- bzw. Auditprü- 
fungen im Betrieb des beauftragten Anbieters durchzuführen und Zugang gewährt 
zu erhalten. § 809 BGB gibt ergänzend ein Recht zur Besichtigung von Sachen, 
nicht aber auf Auskunftserteilung, Nachforschung oder Durchsuchung. 378 Eine 
besichtigungsfähige Sache kann etwa ein Testprodukt oder eine Testeinrichtung 
sein. Möglich ist weiter ein Anspruch des Kunden auf Einsicht in QM-Unterlagen 
nach § 810 BGB. „Urkunde“ i.S.v. § 810 BGB können auch QM-Dokumentationen 



376 Pilz, Qualitätssicherung für Software, in: Nicklisch (Hrg), Verträge über Computer- 
technik in Forschung, Verwaltung, Wirtschaft und Technik 1990, 221, 224. 

377 Ein „Audit“ wird in EN/ISO 9000:2000 Nr. 3.9.1 als systematischer, unabhängiger und 
dokumentierter Prozess zur Erlangung von Auditnachweisen und zu deren objektiver 
Auswertung zur Ermittlung der Erfüllung von Auditkriterien definiert. 

BGH ZUM 2004, 378, 379. 



378 
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und -aufzeichnungen sein. Hierbei genügt es, dass derartige Urkunden zumindest 
auch im Interesse des Kunden errichtet sind 379 . 

Besondere Qualitätssicherungsvereinbarungen können den Anbieter verpflich- 306 
ten, etwa den Kunden „über die erkannten Fehler in der Fertigung, deren Ursa- 
chen und Abstellmaßnahmen zu informieren“. 380 Diese Ursachensuche und die 
erforderlichen Abstellmaßnahmen sind untrennbar mit Qualitätssicherung ver- 
bunden. Nach EN/ISO 9004:2000 Nr. 8.2. 1.3 soll das interne Audit u.a. umfassen: 

• Wirksame und effiziente Prozessverwirklichung, 

• wirksamer und effizienter Einsatz statistischer Verfahren, 

• Einsatz von Informationstechnik, 

• Analyse von Daten zu den Qualitätskosten, 

• Ergebnisse und Erwartungen bezüglich der Prozess- und Produktleistung, 

• Angemessenheit und Genauigkeit der Leistungsmessung, 

• Nachweise hervorragender Leistungen zwecks Anerkennung und Motivierung. 

Unter dem Begriff „Total Quality Management“ (TQM) versteht man „eine auf 307 
die Mitwirkung aller ihrer Mitglieder gestützte Managementmethode einer Orga- 
nisation, die Qualität in den Mittelpunkt stellt und durch Zufriedenstellung der 
Kunden auf langfristigen Geschäftserfolg sowie auf Nutzen für die Mitglieder der 
Organisation und für die Gesellschaft abzielt“ 381 , also ein System aufeinander 
abgestimmter Elemente, die sich gegenseitig voraussetzen und unterstützen 382 . 
Qualität wird nicht neutral-abstrakt, sondern in Abhängigkeit von Kundenan- 
forderungen definiert. Dies ist bezüglich der notwendigen Marktorientierung 
zwar sicherlich vorteilhaft, erschwert aber eine konsistente Definition von Eigen- 
schaften, da diese Definition stark von situativen Kundenbezügen abhängig ge- 
macht wird. Für Kunde A kann Qualität etwas anderes bedeuten als für Kunde B. 

Checkliste: Prüfung des QS-Systems 383 

1. Hat der Anbieter ein QS-System eingeführt? Wird es durchgängig angewendet? 

2. Wird das QS-System in einem Handbuch dokumentiert? Erfasst es auch Tools 
und Individualentwicklungen? Ebenso die Kontrolle ausgelieferter Programm- 
kopien? 



379 BGH WM 1971, 565. 

380 Merz, Qualitätssicherungsvereinbarungen. Zulieferverträge, Vertragstypologie, Risiko- 
verteilung, AGB-Kontrolle 1992, 356. 

381 DIN- bzw. EN-/ISO 8402 (1995). 

382 Mellisl Herzwurml Stelzer, TQM der Softwareentwicklung, 21. 

383 S. näher Schomisch, NJW-CoR 3/1997, 154. 
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3. Wie werden Fehlerkorrekturen behandelt (etwa bei Mängelbeseitigung, War- 
tung/Pflege), wie Änderungen in der Leistung? 

4. Erfolgt eine (dokumentierte!) Testplanung? 

5. Welche inhaltlichen Normen zur Software-Entwicklung sind projekteinschlä- 
gig? 

6. Wurden klare Vereinbarungen bezüglich der Abnahmeprozeduren getroffen? 

7. Erlaubt ein installiertes Konfigurationsmanagement das Identifizieren und 
Rückverfolgen von ausgelieferter Software und Änderungen an dieser? 

8. Ist ein nahtloser Anschluss an Wartungs-/Pflegeleistungen sichergestellt? 

d) Zusammenhang der Normen EN/ISO 9000:2005, 9001 :2000 und 9004:2000 

308 Zentrale Normen für die QS von Produkten und Dienstleistungen sind EN/ISO 
9000:2005, 9001:2000 und 9004:2000. Die Normen EN/ISO 9001:2000 und 
9004:2000 enthalten nur formale Beschreibungen für Verfahren, Modelle und 
Methoden der Qualitätssicherung, keinen vollständigen Satz an Vorschriften für 
die Einrichtung eines konkreten Qualitätsmanagementsystems für spezifische 
Produkte (oder Dienstleistungen), sondern vielmehr nur den Rahmen zum Quali- 
tätsmanagement jeder Produktion oder Dienstleistungserbringung. Im Einzelfall 
kann die Qualitätssicherung auch durch Darlegung anderer organisatorischer und 
technischer Maßnahmen erfolgen, die aber grundsätzlich gleichwertig sein müs- 
sen. Sie gelten auch für Hardware- wie Software-Produkte und -Dienstleistungen 
sowie für die Erstellung und Wartung komplexer Systeme. Die EN/ISO-Vorgaben 
beschreiben als Prozessnormen deshalb nur ein Organisationsmodell, nicht hin- 
gegen bestimmte Prüfinhalte zu Leistungskriterien, die von EDV-Komponenten 
erfüllt werden müssen. 

309 DIN/ISO 9000, Teil 3 gilt noch unverändert als deutsche, nicht europäische Norm 
neben den EN/ISO-Normen weiter und stellt einen Leitfaden für die Anwendung 
der Norm DIN/ISO 9000 auf die Entwicklung, Lieferung und Wartung von Soft- 
ware dar. 384 Die Norm soll Anleitungen geben, wenn ein Vertrag zwischen zwei 
Partnern vom Lieferanten den Nachweis seiner Fähigkeit verlangt, Softwarepro- 
dukte zu entwickeln (Design-Leistung), zu liefern und zu warten (DIN/ISO 9000, 
Teil 3, Nr.l), schreibt aber kein bestimmtes Vorgehensmodell vor. DIN/ISO 9000 
Teil 3 ist eine von mehreren Möglichkeiten, DIN/ISO 9001 zu erfüllen. 385 

310 Zunächst ist ein Entwicklungsplan zu erstellen, in dem die Projektziele und ent- 
sprechenden -mittel personeller und organisatorischer Art ablesbar sein müssen. 
Der Entwicklungsplan sollte einen Projektplan umfassen, der alle durchzuführen - 



384 DIN/ISO 9000 Teil 3 wurde bisher nicht für die Version ISO 9001:2000 überarbeitet 
( Thaller , ISO 9001:2000, 38). 

385 OskarssonIGlass, ISO 9000, 45. 
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den Aufgaben festlegt und für jede der Aufgaben die nötigen Mittel und die benö- 
tigte Zeit sowie die Wechselbeziehungen zwischen den Aufgaben genau bezeichnet 
(DIN/ISO 9000 Teil 3 Nr. 5.4.1). Dieser Projektplan muss für die Vertragsparteien 
Grundlage der an den Entwicklungsphasen orientierten Prüfung der schrittwei- 
sen Vertragserfüllung sein. Hierbei ist konkret festzulegen, zu welchen Milestones 
welche Tests mit welchen Testdaten durchzuführen sind bzw. vom Anbieter 
durchgeführt worden sein müssen und an welchen Kriterien sich bemisst, ob ein 
Entwicklungsteilziel erreicht wurde. Hierbei ist nicht allein Fehlerfreiheit zu tes- 
ten, sondern auch, ob die Leistungsziele (etwa ein Laufzeitverhalten bei bestimm- 
ten Datenmengen) erfüllt ist. Der Entwicklungsplan sollte außerdem die erforder- 
lichen Methoden und Werkzeuge zur Software-Erstellung festlegen (DIN/ISO 
9000 Teil 3, Nr. 5.4.2. 3). Die Norm enthält außerdem wesentliche Regelungen 
zu Konfigurationsmanagement, Dokumentenlenkung, Qualitätsaufzeichnungen, 
Messungen sowie Werkzeugen und Techniken. 

Das Software-Entwicklungsprojekt sollte nach einem der verschiedenen im Be- 311 
reich des Software-Engineering entwickelten Lebenszyklusmodelle organisiert 
sein und qualitätsbezogene Tätigkeiten sollten unter Berücksichtigung der Art des 
verwendeten Lebenszyklusmodells geplant und verwirklicht werden (vgl. näher 
DIN/ISO 9000 Teil 3, Nr. 5.1). 386 

Die Norm EN/ISO 9001: 2000 enthält die Forderungen an QM-Systeme. Maßge- 312 
bend sind die acht Grundsätze des Qualitätsmanagements: Kundenorientierung, 
Verpflichtung der Unternehmensleitung auf die Qualitätsziele, systemorientiertes 
Managementkonzept, ständige Verbesserung, Ausrichten der Entscheidungsfin- 
dung an Fakten und wechselseitiger Nutzen von Lieferantenbeziehungen. EN/ISO 
9001:2000 soll die Wahl eines prozessorientierten Ansatzes für die Entwicklung, 
Verwirklichung und Verbesserung eines QM-Systems fördern und legt als die 
zentrale Norm Anforderungen für interne Anwendungen durch Organisationen 
oder für Zertifizierungs- oder Vertragszwecke fest, nämlich insbesondere Vorga- 
ben für ein QM-Handbuch (Nr. 4.2.2) sowie die Lenkung von Dokumenten 
(Nr. 4.2.3) und Aufzeichnungen (Nr. 4.2.4), die Verpflichtungen der obersten 
Leitung des Unternehmens (Nr. 5.1), die Planung von Qualitätszielen (Nr. 5.4.2) 
und des QM-Systems (Nr. 5.4.2), Entwicklungsplanung (Nr. 7.3.1) und Organisa- 
tion des Beschaffungsprozesses (Nr. 7.4.1). EN/ISO 9001:2000 enthält weitgehend 
Muss- Vorschriften, deren Einhaltung etwa Voraussetzung für eine Zertifizierung 
darstellen. Die Art der Ausgestaltung kann aber auch bei Muss- Vorschriften un- 
terschiedlich erfolgen (EN/ISO 9001:2000, Nr. 0.1, 1. Absatz). 



386 Ausf. s. Koch, Handbuch des Software- und Datenbankrechts, § 6 Rdn. 50 
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313 Die Norm EN/ISO 9004:2000 beinhaltet einen Leitfaden zu den technischen, 
administrativen und menschlichen Faktoren, welche die Qualität von Produkten 
und Dienstleistungen beeinflussen. EN/ISO 9004 betont, über EN/ISO 9001 hin- 
aus, das Zufriedenstellen der Kundenerfordernisse, das Festlegen der funktionalen 
Verantwortlichkeiten und die Wichtigkeit der Abschätzung der potentiellen Risi- 
ken und des möglichen Nutzens. Ersatzlos entfallen ist die Norm DIN/ISO 9004, 
Teil 2, die einen Leitfaden zur Qualitätssicherung von Dienstleistungen enthielt. 
Die Normen in EN/ISO 9004:2000 haben als Leitfaden eher empfehlenden Cha- 
rakter, verwenden deshalb vielfach Soll-Vorschriften und sollen Anleitungen für 
einen im Vergleich zu EN/ISO 9001 erweiterten Bereich von Zielen des QM- 
Systems geben, um insbesondere die Gesamtleistung, Effizienz und Wirksamkeit 
einer Organisation ständig zu verbessern (EN/ISO 9004:2000, Nr. 0.3, 3. Abs.). 

Die Normen DIN/ISO 9002 und DIN/ISO 9003 sind entfallen. 

e) Konfigurationsmanagement 

314 Konfigurationsmanagement im Sinne des Qualitätsmanagements soll helfen, die 
Versionen jedes Software-Elementes oder Produktes und dessen Änderungen zu 
identifizieren, zu lenken und rückzuverfolgen (DIN/ISO 9000 Teil 3, Nr.6.1.1). 
Jede Änderung eines Softwareelements sollte mittels geeigneter Verfahren unter 
dem Konfigurationsmanagement identifiziert, dokumentiert, überprüft und frei- 
gegeben werden. Alle Änderungen sollten diesen Verfahren folgen. Eine Ände- 
rung sollte erst nach Bestätigung ihrer Gültigkeit und Feststellung und sorgfältiger 
Untersuchung ihrer Auswirkung auf andere Produkte angenommen werden. Mel- 
dungen der von den Änderungen Betroffenen sowie Darlegungen der Rückver- 
folgbarkeit zwischen den Änderungen und den modifizierten Teilen der Software- 
elemente sollten methodisch erfasst werden (vgl. DIN/ISO 9000 Teil 3, Nr. 6.1. 3.2). 

315 Das Konfigurationsmanagement stellt in vertragsrechtlicher Sicht die zu verein- 
barende Form der Leistungserbringung dar. Dem Anbieter wie dem Kunden er- 
möglicht es, den jeweiligen Entwicklungsfortschritt der Leistungserbringung zu 
prüfen und einen vertraglichen Leistungsfortschritt (mit entsprechenden Teilver- 
gütungspflichten des Kunden) festzustellen. Hierfür müssen freilich beide Seiten 
verbindliche Terminsequenzen für die Entwicklungsstufen vereinbaren, ebenso 
ein Zugangsrecht und/oder Recht des Kunden auf Einsicht in die Anbieterunterla- 
gen sowie auf Erhalt einer Kopie der kompletten QS-Dokumentation. 

f) Dokumentation 

316 Das QM-System ist zu dokumentieren (EN/ISO 9001:2000 Nr. 4.1). Diese Doku- 
mentation muss insbesondere die Qualitätspolitik und -ziele, ein QM-Handbuch 
und die Verfahren umfassen (EN/ISO 9001:2000 Nr. 4.2.1). Ein Zugangs- und 
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Einsichtsrecht des Kunden kann zumindest individualvertraglich im IT-Projekt- 
vertrag vereinbart werden. 

g) Produktrealisierung 

Die Geschäftsleitung des Anbieters muss die Prozesse zur Produktrealisierung 317 
planen und realisieren und hierfür gemäß EN/ISO 9001:2000 Nr. 7.1 festlegen: 

a) Qualitätsziele und Anforderungen für das Produkt; 

b) die Notwendigkeit, Prozesse einzuführen, Dokumente zu erstellen und die 
produktspezifischen Ressourcen bereitzustellen; 

c) die erforderlichen produktspezifischen Verifizierungs-, Validierungs-, Überwa- 
chungs- und Prüftätigkeiten sowie die Produktannahmekriterien; 

d) die erforderlichen Aufzeichnungen, um nachzuweisen, dass die Realisierungs- 
prozesse und resultierende Produkte die Anforderungen erfüllen. 

Nach der Anleitung in EN/ISO 9004:2000 Nr. 7.1 sollte die Geschäftsleitung den 
wirksamen und effizienten Ablauf der Realisierungs- und Unterstützungsprozesse 
und des zugehörigen Prozessnetzwerks sicherstellen. Letzeres ergibt sich aus der 
wechselseitigen Abhängigkeit von Prozessen. Weiter sollten Prozesse in dem Um- 
fang dokumentiert werden, der zur Unterstützung eines wirksamen und effizienten 
Ablaufs erforderlich ist. Die prozessbezogene Dokumentation sollte unterstützen: 

• Das Erkennen und Kommunizieren wichtiger Merkmale der Prozesse, 

• Schulungen zur Ausführung der Prozesse, 

• die gemeinsame Nutzung von Wissen und Erfahrungen in Arbeitsgruppen, 

• Messung und Bewertung von Prozessen und 

• die Analyse, Bewertung und Verbesserung von Prozessen. 

Teil der Produktrealisierung ist das Leiten und Lenken von Prozessen. Anlei- 318 
tungen hierzu enthält EN/ISO 9004:2000 Nr. 7.1.3. Die Geschäftsleitung sollte 
hiernach zur Sicherstellung der Produktrealisierung sowohl zugehörige Unter- 
stützungsprozesse als auch gewünschte Ergebnisse, Prozess-Schritte, Tätigkeiten, 
Abfolgen, Lenkungsmaßnahmen, Schulungsbedarf, Ausrüstung, Methoden, In- 
formationen, Materialien und sonstige Ressourcen berücksichtigen. Insbesondere 
sollte hierzu ein Arbeitsplan zum Leiten und Lenken der Prozesse festgelegt wer- 
den, der einschließt: 

• Eingabe- und Ergebnisanforderungen (z.B. Spezifikationen und Ressourcen), 

• Tätigkeiten in den Prozessen, 

• V erifizierung und V alidierung von Prozessen und Produkten, 

• Analyse des Prozesses einschließlich Zuverlässigkeit, 

• Risikoerkennung, -bewertung und -minderung, 
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• Korrektur- und Vorbeugungsmaßnahmen, 

• Möglichkeiten und Maßnahmen zur Prozessverbesserung und 

• Lenkung von Änderungen an Prozessen und Produkten. 

319 Prozesseingaben wie -ergebnisse sollten aufgezeichnet werden (EN/ISO 9004:2000 
Nr. 7.1. 3.2 für Eingaben und Ergebnisse). Die Ergebnisse sollten zum Zweck der 
Verifizierung dokumentiert und anhand der Eingabeanforderungen und Annah- 
mekriterien beurteilt werden. Diese Beurteilung sollte notwendige Korrektur- und 
Vorbeugungsmaßnahmen oder mögliche Verbesserungen der Prozesswirksamkeit 
und -effizienz ermitteln (EN/ISO 9004:2000 Nr. 7.1. 3. 2). Nach dieser Norm sollte 
die Geschäftsleitung eine regelmäßige Bewertung der Prozessleistung vornehmen, 
um sicherzustellen, dass der Prozess dem Arbeitsplan entspricht. 

h) Entwicklung 

320 Die Geschäftsleitung muss die Entwicklung des Produkts planen und lenken und 
hierbei die Entwicklungsphasen, für jede Entwicklungsphase die angemessene Be- 
wertung, Verifizierung und Validierung sowie die Verantwortungen und Befugnisse 
festlegen (EN/ISO 9001:2000 Nr. 7.3.1), ebenso zu ermittelnde und aufzuzeichnende 
Eingaben zu Funktions- und Leistungsanforderungen, gesetzliche und behördliche 
Anforderungen (EN/ISO 9001:2000 Nr. 7.3.2) in einer Form, die eine Verifizierung 
gegenüber den Entwicklungseingaben erlaubt (Nr. 7.3.3). Durchgeführt werden 
müssen in geeigneten Phasen systematische Entwicklungsbewertungen (Nr. 7.3.4), 
Entwicklungsverifizierungen (Nr. 7.3.5) und -Validierungen (Nr. 7.3.6). Schließlich 
müssen Entwicklungsänderungen gekennzeichnet und aufgezeichnet werden. Diese 
Änderungen müssen, soweit angemessen, bewertet, verifiziert 387 , validiert 388 , aufge- 
zeichnet sowie vor ihrer Einführung genehmigt werden (Nr. 7.3.7). An Entwick- 
lungsbewertungen müssen Vertreter der Funktionsbereiche teilnehmen, die von der 
bewerteten Entwicklungsphase betroffen sind. Ergebnisse und notwendige Maß- 
nahmen müssen aufgezeichnet werden (Nr. 7.3.4). 

321 Die Geschäftsleitung sollte u.a. Lebenszyklus, Sicherheit und Gesundheit, Prüf- 
barkeit, Nutzbarkeit, Benutzerfreundlichkeit, Zuverlässigkeit, Dauerhaftigkeit, 
Ergonomie, Umwelt, Entsorgung und erkannte Risiken beachten und in einer 



387 „Verifizierung“ wird in EN/ISO 9000:2005 Nr. 3.8.4 definiert als „Bestätigung durch 
Bereitstellung eines objektiven Nachweises, dass festgelegte Anforderungen erfüllt wor- 
den sind“. Verifizierung erfolgt also gegen einen objektiven Maßstab, der nicht auf be- 
sondere Kundenanforderungen abstellt. 

388 „Validierung“ wird in EN/ISO 9000:2005 Nr. 3.8.5 definiert als „Bestätigung durch 
Bereitstellung eines objektiven Nachweises, dass die Anforderungen für einen spezifi- 
schen beabsichtigten Gebrauch oder eine spezifische beabsichtigte Anwendung erfüllt 
worden sind.“ Validierung beinhaltet also, anders als die Verifizierung, die Beurteilung 
gegen den variablen Maßstab subjektiv unterschiedlicher Kundenanforderungen. 
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Risikoabschätzung das Potential für und die Auswirkungen von möglichen Ausfäl- 
len oder Fehlern von Produkten oder Prozessen erkennen (EN/ISO 9004:2000 Nr. 
7.3.1). Hierbei sind u.a. neben externen und sachlich-technischen Faktoren auch 
solche beteiligter Personen (wie Arbeitnehmern) zu berücksichtigen, so etwa An- 
forderungen an die Fähigkeiten der Entwickler (EN/ISO 9001:2000 Nr. 7.3.2 b). 

Auf dieser Basis sollte die Geschäftsleitung geeignete Personen mit der Leitung, 322 
Lenkung und Durchführung systematischer Bewertungen beauftragen, um zu 
ermitteln, ob die Entwicklungsziele erreicht wurden (EN/ISO 9004:2000 Nr. 7.3.3). 
Verifizierungen können etwa erfolgen durch Vergleiche der Eingabeanforderun- 
gen mit den Prozessergebnissen (Nr. 7.3.3). 

Die Geschäftsleitung muss die Merkmale des Produkts in geeigneten Phasen der 323 
Produktion überwachen und messen, um die Erfüllung der Produktanforderun- 
gen zu verifizieren, und einen Nachweis der Konformität mit den Annahmekrite- 
rien führen. Hierbei müssen in den Aufzeichnungen die für die Freigabe des Pro- 
dukts zuständigen Personen angegeben werden (EN/ISO 9001:2000 Nr. 8.2.4). Die 
Geschäftsleitung muss geeignete Methoden zur Überwachung und Messung wäh- 
len, die auch ein Ergreifen von Korrekturmaßnahmen ermöglichen (EN/ISO 
9001:2000 Nr. 8.2.3). 

Nach EN/ISO 9004:2000 Nr. 8.1.1 soll die Geschäftsleitung Messungen sowie 324 
Datenerfassung und -Validierung ständig überwachen und aufzeichnen und die 
Ergebnisse der Datenanalysen in die Managementbewertung aufnehmen. Es soll- 
ten Daten und Informationen aus allen Bereichen des Betriebs zusammenge- 
führt und analysiert werden, um eine wirksame Beurteilung der Gesamtleistung 
zu ermöglichen. 

Zur Beurteilung der Prozesse (der Produktion) soll die Geschäftsleitung nach 325 
EN/ISO 9004:2000 Nr. 8.2.2 auch Faktoren berücksichtigen wie 

• Fähigkeit, 

• Reaktionszeit, 

• Zykluszeit oder Durchsatz, 

• Ausbeute, Wirksamkeit und Effizienz der Personen der Organisation (d.h. der 
Arbeitnehmer), 

• Nutzung von Technologien, etc. 

Qualitätsaufzeichnungen sind zeitgleich auf allen Stufen zu führen, also für Pia- 326 
nung, Entwicklung und Herstellung ebenso wie für Vertrieb und nachvertriebliche 
Produktbeobachtung, Warnungen und evtl. Rückrufe. Lücken in dieser Doku- 
mentation können die Beweislast zugunsten des Geschädigten verschieben und 
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vertragsrechtlich zudem eine Pflichtverletzung darstellen, die das Unternehmen 
schadensersatzpflichtig machen kann. Erforderlich ist eine vollständige Doku- 
mentation der Qualitätssicherung. Unvollständigkeiten der Aufzeichnungen stel- 
len damit einen Verstoß gegen den Stand der Technik dar. Wichtig ist weiter eine 
gesicherte Aufbewahrung der Aufzeichnungen, die im Einzelfall zu einem nicht 
unerheblichen Aufwand zur entsprechenden Archivierung führen kann. 

327 Schließlich muss eine Möglichkeit bestehen, dem Kunden Zugriff auf die Quali- 
tätsaufzeichnungen des Auftragnehmers einzuräumen. Auch ohne entsprechende 
Vereinbarung kann aus § 810 BGB ein Anspruch des Kunden auf Einsicht in ent- 
sprechende Qualitätssicherungsurkunden ableitbar sein. Dies setzt u.a. voraus, 
dass die Urkunde im Interesse des Kunden errichtet wurde. Es lässt sich die Auf- 
fassung vertreten, dass entsprechende Qualitätssicherungsunterlagen zumindest 
auch im Interesse des Kunden errichtet werden, um primär diesen vor der Aus- 
wirkung von Produktfehlern zu schützen (s. oben). 

i) Lenkung fehlerhafter Produkte 

328 DIN/ISO 8402 definiert „Fehler“ als „Nichterfüllung einer festgelegten Forde- 
rung“. DIN 66 271 nennt Kriterien für den Grad einer „Nichterfüllung“ und für 
die Verbindlichkeit einer „Forderung“. Die Norm DIN 66 271 unterscheidet zwi- 
schen Fällen, die auch in der Praxis als Fehler betrachtet werden, und Fällen, in 
denen zwar eine (vertraglich festgelegte) Forderung verletzt wird, die aber wegen 
der Geringfügigkeit der Nichterfüllung oder wegen der Unverbindlichkeit der 
Forderung in der Praxis nicht als Fehler gewertet werden. Die Norm DIN 66 271 
bezeichnet hierbei eine Nichterfüllung, deren vertragliche Wertung noch nicht 
entschieden ist, als „Abweichung“. Vor diesem Flintergrund legt die Norm Krite- 
rien für die Beurteilung von Abweichungen in vertraglich bestimmten Situationen 
fest, beschreibt deren Behandlung und definiert die dafür notwendigen Begriffe. 

329 DIN 66 271 beschreibt Kriterien 

• für die Erfassung, Analyse und Beurteilung von Abweichungen, die während 
der Entwicklung, bei der Abnahme oder im Einsatz von Produkten auftreten, 

• für die Einigung darüber, ob Fehler sachlich eine Korrektur erfordern und ob 
sie vertraglich eine Abnahme verhindern oder der Gewährleistung unterliegen. 

330 Die Geschäftsleitung muss sicherstellen, dass ein Produkt, das die Anforderungen 
nicht erfüllt, gekennzeichnet und gelenkt wird, um seinen unbeabsichtigten 
Gebrauch oder seine Auslieferung zu verhindern, und sie muss diese Lenkungs- 
maßnahmen und zugehörige Verantwortlichkeiten und Befugnisse in einem do- 
kumentierten Verfahren festlegen sowie getroffene Maßnahmen und Ergebnisse 
ihrer Durchführung dokumentieren. Weiter muss ein nachgebessertes Produkt 
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zur Darlegung der Konformität erneut verifiziert werden (EN/ISO 9001:2000 Nr. 

8.3). Damit werden auch Leistungen eines Arbeitnehmers zur Mängelbeseitigung 
in den Kontroll- und Dokumentationsprozess einbezogen. 

EN/ISO 9001:2000 Nr. 8.5.2 (ebenfalls Muss- Vorschrift) verpflichtet die Ge- 331 
schäftsleitung außerdem ausdrücklich, angemessene Korrektur- und Vorbeu- 
gungsmaßnahmen (als Formen der Verbesserung) zur Beseitigung der Ursachen 
von Fehlern zu ergreifen, um deren erneutes Auftreten zu verhindern, und hierfür 
ein dokumentiertes Verfahren einzuführen. 

Die Geschäftsleitung sollte den Personen der Organisation (d.h. Arbeitnehmern) 332 
die Befugnis und Verantwortung übertragen, in jedem Stadium eines Prozesses 
Fehler zu melden, um deren rechtzeitige Entdeckung und Beseitigung sicherzu- 
stellen (EN/ISO 9004:2000 Nr. 8.3.1, 1. Abs.). Zur Überprüfung müssen der Ent- 
decker eines Fehlers und das Entdeckungsdatum aufgezeichnet werden. 389 Eine 
solche Meldung steht im Einklang mit den Erfordernissen des Qualitätsmanage- 
ments. Ohne derartige Meldungen kann es geschehen, dass Fehler nicht so früh 
wie möglich (bzw. überhaupt nicht) vor Inverkehrbringen beseitigt werden, wo- 
durch sich ihre negativen Auswirkungen deutlich erhöhen können (und sei es nur 
dadurch, dass der Fehler auch in den weiteren Exemplaren eines Serienproduktes 
erhalten bleibt und kostenaufwendig nachträglich beseitigt werden muss). 

Fehler sollten zusammen mit ihrer Behandlung aufgezeichnet werden (EN/ISO 333 
9004:2000 Nr. 8.3.1 3. Abs.). Erkannte Fehler sollten in einem wirksamen und 
effizienten Prozess bewertet und behandelt werden. Die zuständigen Arbeitneh- 
mer sollten zur Beurteilung der gesamten Wirkungen von Fehlern befähigt sein 
und über die Ressourcen zur Fehlerbehebung und zur Festlegung geeigneter Kor- 
rekturmaßnahmen verfügen (EN/ISO 9004:2000 Nr. 8.3.2). 

j) Produktnormen 

Anders als verfahrensorientierte Prozessnormen sind Produktnormen auf die 334 
Eigenschaften des fertigen Produkts ausgerichtet. Zu Produktnormen gehören z.B. 
die „Allgemeinen Grundsätze für die Herstellung von Waren“ (DIN 66051) und 
spezifische Prüfbestimmungen nach DIN, VDE und RAL. Auch Prüfverfahren 
können vorgeschrieben sein, z.B. mechanische oder Ultraschallprüfungen, röntge- 
nologische, UV- und Laserprüfungen. Derartige inhaltlich-fachliche Qualitäts- 
normen bestimmen die normale Beschaffenheit von Gegenständen 390 (z.B. VDE- 
oder DIN-Normen). Aus produkthaftungsrechtlicher Sicht stellen sie eine wider- 



389 Wagner (Hrg.), PQM - Prozessorientiertes Qualitätsmanagement, 214. 

390 Kullmannl Messer, Produkthaftung, Kap. 1410, S. 13. 
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legbare Vermutung des Standes der Technik dar. 391 Gegenüber Vertragspartnern 
ist ihre Einhaltung 392 als Sollbeschaffenheit geschuldet. Der Stand von Wissen- 
schaft und Technik kann aber über den der jeweiligen Normen hinausgegangen 
sein; maßgeblich ist dann dieser aktuelle Stand. 393 Beispiele für Produktnormen: 

335 ISO 12119 (1994) 394 beschreibt Qualitätsanforderungen und Prüfbestimmungen 
für Endprodukte. 395 Die Anforderungen betreffen die Beschreibungen des Pro- 
dukts, die Dokumentation, die Programme und Daten sowie die durchzuführen- 
den Prüfungen. Die Prüfungen für Programme erfassen im Regelfall nur Black- 
box-Tests. In der Produktbeschreibung müssen die implementierten Funktionen 
und alle für die Anwendungssoftware wesentlichen Randbedingungen ausgeführt 
sein. Die Vertragsparteien können (und sollten) diese Qualitätsanforderungen als 
Grundlage für eine Prüfung verwenden, ob und inwieweit der Anbieter seine Leis- 
tung vertragsgerecht erbracht hat. 

336 Der Kunde kann zunächst eine Produktbeschreibung verlangen (DIN 12 119 
Nr. 2.3 und 3.1), die mit dem Vertrag Grundlage bereits bei den Vertragsverhand- 
lungen sein sollte, die ihrerseits wiederum ein (gesetzliches) Schuldverhältnis be- 
gründen (§311 Abs. 2 Nr. 1 BGB). Die Produktbeschreibung legt Angaben über 
die Dokumentation, die Programme und gegebenenfalls die Daten fest. Die Über- 
prüfung erfolgt nach den Güte- und Prüfbedingungen (GuP) Anwendungssoft- 
ware im Rahmen der RAL-GZ 901 und DIN 12 119. Die Produktbeschreibung 
muss dafür ausreichend verständlich, ausführlich und übersichtlich sowie in sich 
widerspruchsfrei sein. Es sollten weitere Produkteigenschaften beschrieben wer- 
den, die die Funktionsfähigkeit des Produkts sichern. Beispiele: Zugangsüberwa- 
chung, Plausibilitätsprüfungen, Schutz vor unerwünschten Folgen von Fehlbedie- 
nung, Wiederanlauf. Die Art der Benutzerschnittstelle ist zu beschreiben, so etwa 
Menüführung, Fenstertechniken, Funktionstasten, Hilfefunktionen. Wenn die 
Produktbeschreibung Schnittstellen zu anderen Produkten erwähnt, so sind die 
Schnittstellen oder das Produkt genau zu bezeichnen. Es ist die zur Anwendung 
des Produkts hinreichende Mindestkonfiguration der Hardware zu bezeichnen, 
z.B. Zentraleinheit, Code-Prozessoren, Hauptspeichergröße, Arten und Größen 
peripherer Speicher, Erweiterungskarten, Ein- und Ausgabegeräte. Für verschie- 



391 Kulimann/ Messer, Produkthaftung, Kap. 1410, S. 13. 

392 Zum Themenbereich Qualitätssicherungsvereinbarungen s. Graf v. Westphalen, Quali- 
tätssicherung, in: Röhricht/ Graf v. Westphalen, HGB-Kommentar 1998. 

393 Kullmann/Pfister, Produkthaftung, Kap. 1520, S. 11. 

394 DIN/ISO/IEC 12 119 (früher DIN 66 285), „Software-Erzeugnisse - Qualitätsanforde- 
rungen und Prüfbestimmungen“, basiert auf DIN 66 285, 1995-08, Konformitätsprü- 
fung, ausführliche Produktbeschreibung, Dokumentation, Programm und Daten. 

395 Kneuperl Sollmann, Normen zum Qualitätsmanagement bei der Softwareentwicklung, 
Informatik-Spektrum 18 (1995), 314, 319, 320. 
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dene Arbeitsaufgaben, verschiedene Grenzwerte oder verschiedene Effizienzan- 
forderungen können verschiedene Mindestkonfigurationen angegeben werden. 

Die Produktbeschreibung muss jeden physischen Bestandteil der Lieferung be- 
zeichnen, insbesondere alle gedruckten Dokumente und alle Datenträger, ebenso 
die Form, in der die Programme ausgeliefert werden, z.B. als Quellprogramme, 
Objektprogramme, Lademodule. Anzugeben ist auch, ob die Installierung des 
Produkts durch den Anwender vorgesehen ist und das Produkt einen Kopier- 
schutz aufweist. 

Nach der Produktbeschreibung muss die Installation möglich und anschließend 337 
erkennbar sein, ob die Programme funktionsfähig sind, z.B. durch mitgelieferte 
Prüffälle oder durch Selbstprüffunktionen mit entsprechender Meldung. Alle in 
der Produktbeschreibung oder der Dokumentation angegebenen Funktionen 
müssen in der dokumentierten Form tatsächlich ausführbar sein. Die Programme 
und Daten müssen allen Angaben in der Produktbeschreibung und in der Doku- 
mentation entsprechen. Die Funktionen müssen fachlich richtig ausgeführt wer- 
den und widerspruchsfrei sein. 

ISO/IEC 9216 (1991) beschreibt Ziele der Software-Qualität, nämlich Funktionali- 338 
tät, Zuverlässigkeit, Benutzbarkeit, Effizienz, Wartbarkeit und Porti erbarkeit. 

IEC 1508 beschreibt Anforderungen für elektrische/elektronische/programmier- 339 
bare elektronische Systeme, also Hardware. 

Die Normen IEEE 730-1989 und 983-1986 enthalten Anforderungen zur Quali- 340 
tätssicherung bei insbesondere technischen Software-Projekten, STD 829-1983 
(bestätigt 1991) für Software-Testing. Standard (Std.) 730 sieht einen Software 
Quality Assurance Plan (SQAP) vor, während Std. 983 Hinweise zur Einführung 
und Umsetzung des SQAP enthält. 396 Die (auch mathematisch) anspruchsvollere 
Verifikation und Validation wird in IEEE Std. 1012 beschrieben, Software- Reviews 
und -Audits in Std. 1028. 

Die Normen DIN V 19250 und DIN 19251 beschreiben Anforderungen für Steue- 341 
rungssoftware für MSR(Messen, Steuern, Regeln)-Schutzeinrichtungen. 397 

ANSI/IEEE 1012-1986 enthält Anforderungen für die Verifikation und Validation 342 
von Software. 



396 Kneup er / Sollmann, a.a.O., 316. 

397 Zur Kritik an den Normentwürfen s. Hohlerl Villinger, a.a.O., 69. 
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343 DIN 66 272 beschreibt inhaltliche Qualitätsanforderungen an Software, insbeson- 
dere zu den Qualitätsmerkmalen Funktionalität, Zuverlässigkeit (etwa zur Fehler- 
toleranz), Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit (wichtig für 
Portabilität). Das nationale Vorwort zu DIN 66 272 stellt fest, dass Software- 
Produkte nicht alle genannten Qualitätsmerkmale in möglichst hohem Maße 
erfüllen müssen. „Die Qualität eines Softwareprodukts ist im Sinne von ISO 8402 
dann gut, wenn es die beschriebenen Eigenschaften in einem solchen Umfang 
besitzt, dass es damit den Erfordernissen seiner Anwendung gerecht wird“. 398 

344 Die Norm DIN 66 271 unterscheidet zwischen Fällen, die auch in der Praxis als 
Fehler betrachtet werden, und Fällen, in denen zwar eine (vertraglich festgelegte) 
Forderung verletzt wird, die aber wegen der Geringfügigkeit der Nichterfüllung 
oder wegen der Unverbindlichkeit der Forderung in der Praxis nicht als Fehler 
gewertet wird. Die Norm DIN 66 271 bezeichnet hierbei eine Nichterfüllung, de- 
ren vertragliche Wertung noch nicht entschieden ist, als „Abweichung“. DIN 
66 271 beschreibt Kriterien für die Erfassung, Analyse und Beurteilung von Ab- 
weichungen, die während der Entwicklung, bei der Abnahme oder im Einsatz von 
Software auftreten, ebenso für die Einigung darüber, ob Fehler sachlich eine Kor- 
rektur erfordern und ob sie vertraglich eine Abnahme verhindern oder der Ge- 
währleistung unterliegen. DIN 66 271 listet außerdem Kriterien für Fehler von 
Software und ihre Behandlung im Vertragsverhältnis auf und führt hierzu sechs 
Qualitätsmerkmale von Software an, nämlich Funktionalität, Zuverlässigkeit, 
Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit. Nicht nur die Erst-, 
sondern auch Folgeversionen (etwa im Rahmen der Pflege) müssen mit gleichen 
Maßstäben und Methoden qualitätsgesichert sein. 

k) Informationssicherheit nach IS0 1 7799399 

345 Die International Organization for Standardization (ISO) veröffentlichte im De- 
zember 2000 die erste auf Informationssicherheit bezogene Norm zum „Informa- 
tion Security Management“. Die Norm definiert einen Prozess zum Evaluieren, 
Implementieren, Erhalten und Managen der Informationssicherheit und ist die 
Grundlage für eine mögliche Zertifizierung und damit zukünftig auch für eine 
Auftragsvergabe durch die öffentliche Hand. 400 



398 Vorwort zu DIN 66 272, 1. 

399 Ausf. s. Carlson, Information Security Management: Understanding ISO 17799, Sept. 
2001 . 

www.lucent.com/livelink/209341_Whitepaper.pdf. 

400 In Großbritannien ist dies bereits der Fall, s. Kenning , Security management Standard - 
ISO 17799/BS 7799, BT Technol. J. Vol. 19 No. 3/July 2001 
(www.bt.com/bttj/voll9no3/kenning/kenning.pdf), 132, 136. 




B.15. Öffentliche IT-Projekte zur Beschaffung nach den EVB-IT und den BVB 



117 



I) Qualitätsmanagement für Dienstleistungen 

Nicht nur die Produkterstellung, sondern auch das Erbringen einer Dienstleistung 346 
unterliegt der Qualitätssicherung, die durch Qualitätsmanagement gesteuert wird. 
Ersatzlos entfallen ist die Norm DIN / ISO 9004 Teil 2 Leitfaden für Dienstleistun- 
gen. Als „Dienstleistung“ definiert DIN/ISO 8402 Nr. 1.5 die „durch Tätigkeiten 
an der Schnittstelle zwischen Lieferant und Kunde sowie durch den Lieferanten 
intern erbrachten Ergebnisse der Erfüllung der Erfordernisse des Kunden“. 
„Dienstleistung“ ist nicht auf Leistungen nach Dienstvertrag im Sinne der §§ 611 ff 
BGB beschränkt, sondern erfasst auch z.B. Werkleistungen subbeauftragter Un- 
ternehmer. 

Zwar ist die Norm DIN / ISO 9004 Teil 2 entfallen, jedoch wird in der Praxis ein 347 
QM-System weiterhin vielfach nach den Vorgaben dieser Norm angewendet. Die 
materiellen Vorgaben dieser Norm für Dienstleistungen sind recht weitgehend. 
Berücksichtigt wurden nach DIN/ISO 9004 Teil 2 Nr. 0 (Einleitung) Abs. 5 näm- 
lich Faktoren wie 

• Management der mit einer Dienstleistung verbundenen sozialen Prozesse, 

• Betrachten zwischenmenschlicher Beziehungen als einen wesentlichen Teil der 
Dienstleistungsqualität, ... 

• Entwicklung der Fertigkeiten und Fähigkeiten der Mitarbeiter und 

• Motivierung der Mitarbeiter, die Qualität zu verbessern und Erwartungen der 
Kunden zu erfüllen. 

1 5. Öffentliche IT-Projekte zur Beschaffung nach den EVB-IT und den BVB 
a) Grundlagen 

Bund, Länder und Gemeinden müssen der IT-Beschaffung besondere Vertragsbe- 348 
dingungen zugrundelegen (§ 55 BHO/LHO), 401 damit auch der Durchführung von 
IT-Projekten. Grundlage der Auftragsvergabe ist die „Verdingungsordnung für 
Leistungen“ (VOL). 402 Teil A der VOL regelt die Auftragsvergabe für Lieferungen 
und Leistungen, Teil B die Allgemeinen Vertragsbedingungen für die Ausführung 
von Leistungen für Kauf-, Werk- und Werklieferverträge. 403 Öffentliche Auftrag- 
geber müssen die VOL/B dem Beschaffungsvertrag zugrundelegen. 404 Das Verfah- 



401 Zum Verfahren s. näher Koch, Computer- Vertragsrecht, Rdn. 68ff. 

402 VOL/A 2006 v. 6.4.2006, BAnz. Nr. 100 a v. 30.5.2006; ausf. zum Vergaberecht Hertwig, 
Auftragsvergabe. 

403 Leitzen/Intveen, CR 2001, 493 

404 Leitzen/Intveen , a.a.O. 
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ren folgt der Vergabeverordnung (VgV). 405 Die VgV kann auch für die Regelungen 
zur Vergabe von IT- Aufträgen (BVB/EVB-IT) unmittelbare Relevanz erlangen, 
wenn etwa der Auftraggeber versäumt, unterlegene Bieter spätestens 14 Kalender- 
tage vor dem Vertragsschluss zu informieren und hierdurch der Vertrag nichtig ist 
(§ 13 VgV). 406 

349 Die Vergabe ist europaweit auszuschreiben, 407 wenn bestimmte Schwellenwerte 
der Auftragssumme überschritten werden, für Lieferungen und Leistungen etwa 
211 000 Euro (§ 2 Nr. 3 VgV). Bei gemischten Verträgen (aus Lieferungen und 
Dienstleistungen) gilt der Auftrag nach § 1 a Nr. 1 Abs. 2 VOL/A Abschnitt 2 als 
Dienstleistung, wenn der Wert der im Auftrag enthaltenen Dienstleistungen den 
Wert des Lieferanteils übersteigt (sog. „main value test“ 408 ). Bei komplexen Ver- 
fahren erfolgt die Vergabe des Auftrags im „wettbewerblichen Dialog“ (§ 101 
Abs. 5 GWB). Die „Vertragsabschlussentscheidung“ muss für den Bieter über- 
prüfbar sein. 409 Weiter zu unterscheiden ist zwischen Dienstleistungen, auf die die 
VOL/A anzuwenden ist, und Leistungen im Rahmen freiberuflicher Tätigkeit, die 
der VOL (Verdingungsordnung für freiberufliche Leistungen) 410 folgen. Die Ab- 
grenzungen sind im Einzelfall streitig: Die Programmierung von Systemsoftware 
soll als ingenieurmäßige Leistung freiberuflich sein, die Programmierung von 
Anwendungssoftware hingegen gewerbliche Leistung. 411 



405 Verordnung über die Vergabe öffentlicher Aufträge v. 9.1.2001 (BGBl I 110), in Kraft 
seit dem 1.2.2001, Fassung v. 11.2.2003 (BGBl 2003 I, 169), geändert mit 3. Änderungs- 
VO v. 23.10.2006 (BGBl 2006 I, 2334) und in Kraft seit dem 1.11.2006. 

406 Antweiler, DB 2001, 1975. 

407 Ausf. s. Hertwig, Auftragsvergabe, Rdn. 16 f; zu den Schwellenwerten Hertwig , Auf- 
tragsvergabe, Rdn. 31 ff, 47 ff. EG-rechtliche Grundlage ist die Richtlinie 92/50/EWG 
des Rates vom 18.6.1992 über die Koordinierung der Verfahren zur Vergabe öffentli- 
cher Dienstleistungsaufträge, ABI. EG Nr. L 209 v. 24.7.1992, 1. IT-Dienstleistungen 
sind in Anhang I a, Kategorie 7 der Dienstleistungs-RL definiert als „Dienstleistungen 
bei der Hardware-Beratung, Entwicklung von Software-Paketen, sonstige Dienstleis- 
tungen von Software-Häusern, Dienstleistungen von Datenbanken, Instandhaltungs- 
und Reparaturarbeiten an Büromaschinen, Datenverarbeitungsgeräten und -einrich- 
tungen sowie sonstige, mit der Datenverarbeitung verbundene Dienstleistungen“. Liefe- 
rungen als solche sind geregelt in der Richtlinie 93/36/EWG des Rates über die Koordi- 
nierung der Verfahren zur Vergabe öffentlicher Lieferaufträge, ABI. EG Nr. L 199 
v. 9.8.1993, 1 (sog. „Lieferkoordinierungsrichtlinie“). Lieferungen sind in § 99 Abs. 2 
GWB definiert. 

408 Kulartz/Steding, IT-Leistungen. Fehlerfreie Ausschreibungen und rechtssichere Ver- 
tragsinhalte 2002, 9. 

409 EuGH NJW 2000, 569; Kus, NJW 2000, 544. 

410 VOF 2006 v. 16.3.2006, BAnz. Nr. 91 av. 13.5.2006. 

411 Kulartz/Steding, IT-Leistungen, 11. 
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Auch nichtöffentliche Anwender, also etwa Unternehmen, überlegen zuweilen, auf 350 
Regelungen dieser Vertragsbedingungen zurückzugreifen. Hier erscheint Vorsicht 
angebracht. Immerhin sind eine Reihe spektakulär gescheiterter IT-Projekte, über 
die die Computerpresse regelmäßig berichtet 412 , auf eben diese Vertragsbedingun- 
gen gestützt. Zu vermuten ist, dass die von der öffentlichen Hand verwendeten 
Vertragsbedingungen strukturelle Schwächen aufweisen und deshalb kein ausrei- 
chendes Instrumentarium zur Bewältigung von Projektkrisen bieten. Bestätigt 
wird diese Vermutung etwa durch die eher milde Vertragsstrafenregelung. 413 

b) Besondere Vertragsbedingungen (BVB) und Ergänzende Vertragsbedingungen (EVB-IT) 

Für die Vergabe im EDV-Bereich wurden zunächst die Besonderen Vertragsbe- 351 
dingungen (BVB) 414 entwickelt, die freilich bereits überwiegend aus den Siebziger - 



412 Die Computerwoche 51-52/2004, 28 und 27/2005, 11 nennt etwa das Steuersystem 
„Fiscus“ für bundeseinheitliche Steuersoftware, das nach 13 Jahren Projektdauer und 
einem dreistelligen Investitionsbetrag 2004 nach Scheitern neu ausgerichtet wurde, und 
das „Herkules“-Projekt der Bundeswehr, über dessen Umfang Bund und Anbieterkon- 
sortium keine Einigung erzielen konnten und das 2004 scheiterte, jedoch 2006 wieder 
aufgenommen wurde. Für das „Inpol“-Projekt des BKA stiegen die Kosten von 40 Mil- 
lionen auf 280 Millionen DM (Computerwoche 43/2001, 14). Vom Scheitern bedroht 
war auch das „Basis 3000“-Projekt des Berliner Senats für 3000 Mitarbeiter der Berliner 
Sozialämter (Computerwoche 48/2000, 67). 

413 So sieht § 10 Nr. 1 BVB-Erstellung eine nach 30 Kalendertagen (oder nach vereinbarter 
Dauer) einsetzende Vertragsstrafe von 1/1500 der Vergütung für die in Verzug geratene 
Leistung vor, wobei die Zahlungspflicht auf maximal 100 Verzugstage beschränkt ist. 
Sind nun etwa für eine Software im gesamten Auftragsumfang von € 500.000 (verein- 
facht zu Beispielszwecken) zehn Module zu je € 50.000 geschuldet und gerät der Anbie- 
ter mit Modul 6 für zwei Monate in Verzug, schuldet er ab dem 31. Kalendertag maxi- 
mal 50.000 x 1/1500 x 30 = € 999,99, also insgesamt rund € 1.000, damit maximal 0,2% 
der gesamten Vertragssumme. 

414 Besondere Vertragsbedingungen für den Kauf von EDV-Anlagen und -Geräten (vom 
15.6.1974 (Stand 1.7.1974), Beilage Nr. 15/74 zum Bundesanzeiger Nr. 135 vom 
25.7.1974) 

Besondere Vertragsbedingungen für die Miete von EDV-Anlagen und -Geräten (vom 
15.12.1972 (Stand 1.1.1973), Beilage Nr. 2/73 zum Bundesanzeiger Nr. 23 vom 2.2.1973) 
Besondere Vertragsbedingungen für die Wartung von EDV-Anlagen und -Geräten 
(vom 15.6.1974 (Stand 1.7.1974), Beilage Nr. 15 zum Bundesanzeiger Nr. 135 vom 
25.7.1974) 

Besondere Vertragsbedingungen für die Überlassung von DV-Programmen (vom 
4.11.1977, Beilage Nr. 26/77 zum Bundesanzeiger Nr. 216 vom 19.11.1977) 

Besondere Vertragsbedingungen für das Erstellen von DV-Programmen (vom 
20.12.1985, Anlage 1 zum Bundesanzeiger Nr. 13a vom 21.1.1986) 

Besondere Vertragsbedingungen für die Pflege von DV-Programmen (vom 30.11.1979, 
Beilage Nr. 41/79 zum Bundesanzeiger Nr. 239/79 vom 21.12.1979) 

Besondere Vertragsbedingungen für die Planung von DV-gestützten Verfahren (vom 
24.10.1988, Beilage Nr. 227a zum Bundesanzeiger Nr. 227 vom 6.12.1988). 
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jahren stammen und demzufolge in manchen Punkte veraltet, also etwa deutlich 
mainframe-orientiert 415 sind. Deshalb erfolgte eine Neufassung in den Ergänzen- 
den Vertragsbedingungen EVB-IT 416 . BVB und EVB-IT sind ergänzende Ver- 
tragsbedingungen im Sinne von § 9 VOL/A, die die VOL/B um IT-spezifische 
Besonderheiten ergänzen, 417 also nicht ersetzen. 

352 In der Praxis erweist sich als hinderlich, dass die BVB nicht uno actu von der 
EVB-IT abgelöst wurden. Vielmehr existieren parallel nebeneinander: 418 

• BVB: BVB -Erstellung, BVB-Überlassung Typ II (Überlassung von Program- 
men und die Herbeiführung ihrer Funktionsfähigkeit auf bestimmten EDV- 
Anlagen und -Geräten), BVB-Planung und BVB-Pflege (für Individualsoft- 
ware). 

• EVB-IT: EVB-IT -Überlassung Software Typ A (zeitlich unbefristet) und Typ B 
(zeitlich befristet), jeweils ohne werkvertragliche Leistungskomponenten, EVB- 
IT Kauf Hardware, EVB-IT Dienstleistung (unterstützende Leistungen, z.B. Be- 
ratung, Schulung), EVB-IT Instandhaltung (Hardware) und EVB-IT Pflege S 
(für Standardsoftware). 

353 Weder in den BVB noch in den EVB-IT ist ein geschlossener IT-Projektvertrag 
vorgesehen. In den EVB-IT werden Projektleistungen überhaupt nicht erfasst. Die 
alten BVB sehen nach Anlage 2 zu § 1 BVB-Erstellung für Planung (Vorbereiten 
und Erarbeiten eines Grobkonzepts, Erarbeiten eines fachlichen Feinkonzepts) 
und Erstellung (Erstellen DV-technisches Feinkonzept, Programmieren, etc.) zwei 
Verträge vor. Geplant ist ein EVB-IT-Planungs- und Realisierungsvertrag. 419 

354 Für die Erstellung wie für die Anpassung von Software existieren also noch keine 
EVB-IT. Dies bedeutet für die Praxis, dass sowohl Individualprogrammierungen 
als auch die besonders häufigen Anpassungen und Parametrisierungen nach wie 
vor (Stand Frühjahr) nach den BVB-Erstellung aus dem Jahr 1985 (!) vergeben 
werden müssen. Deshalb regelt § 1 EVB-IT Überlassung S. 2 ausdrücklich, dass 
diese EVB zusätzliche Leistungen wie Installation, Integration, Parametrisierung 
und Anpassung von Standardsoftware nicht erfassen. 



415 Leitzen/Intveen, CR 2001, 493, 494. 

416 Die Anwendung der EVB-IT wurde nach Beschluss des Interministeriellen Koordinie- 
rungsausschusses für Informationstechnik in der Bundesverwaltung (IMKA) von der 
Koordinierungs- und Beratungsstelle für Informationstechnik in der Bundesverwaltung 
im Bundesministerium des Inneren (KBSt) empfohlen (GMB1 Nr. 60, 1188 v. 
28.12.2000). 

417 Leitzen/Intveen, a.a.O., 494. 

418 Alle Regelwerke sind online verfügbar unter www.kbst.bund.de. 

419 Leitzen/Intveen , CR 2001, 493, 496; Müglich, CR 2004, 166f; skeptisch Müller-Hengsten- 
berg, CR 2006, 426, 430 (Kombination BVB-Planung und -Erstellung ausreichend). 
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Vertragsstrafen sind in den EVB-IT nicht (mehr) vorgesehen, können aber über § 12 
VOL/A (nur) für die Überschreitung von Ausführungsfristen vereinbart werden. 420 

16. Kostensenkungen durch Vertragsanpassungen 

Auch in laufenden Verträgen sind in begrenztem Umfang Anpassungen möglich, 355 
die zu einer Senkung von Kostenlasten des Anwenders führen können. Freilich ist 
vorab auf die Verbindlichkeit geschlossener Verträge hinzuweisen 421 . Dennoch 
existieren oft Spielräume für einvernehmliche Vertragsänderungen. Einige Punk- 
te werden nachfolgend zusammengestellt. Naturgemäß ist die Auflistung unvoll- 
ständig. Außerdem ist immer eine rechtliche Einzelfallprüfung notwendig, die den 
Gesamtzusammenhang der Anwendung berücksichtigt. 

Bei Wechsel von Hardware und insbesondere Endgeräten sollte auf Standardisie- 356 
rung und gut verhandelten Einkauf geachtet werden. 422 Die Wartung sollte auf den 
tatsächlich benötigten Level eingestellt werden. Hierbei kann gerätespezifisch zu 
differenzieren sein; die Wartung für Drucker über die gesamte vorgesehene Dauer 
der Nutzung einer Anwendung etwa kann (insbesondere bei Berücksichtigung 
von Personalstundenkosten) wesentlich teurer kommen als ein Nachkauf von 
Standardgeräten. Auch macht allgemein der Einsatz neuerer Technologien die IT 
nicht notwendig in jedem Fall leistungsfähiger; 423 entscheidend ist der jeweilige 
Einsatzzweck (Beispiele: Wechsel zu Duo-Core-Prozessoren bei einfachen Text- 
verarbeitungsanwendungen bringt fast keine Beschleunigung, wenn die Ge- 
schwindigkeit der Texteingabe durch den Menschen unverändert bleibt. Die Ein- 
führung von Vista-Office kann wegen geänderter Befehlsstrukturen umfangreiche 
Umschulungen erforderlich machen). 

Bei Software ist auf die Möglichkeit der Wiederverwendbarkeit von Software 357 
(teilen) zu achten (Template- Verfahren), deren Ausschöpfen allerdings zur Konse- 
quenz hat, dass bestimmte Softwareteile (z.B. Klassenbibliotheken) früher für ande- 
re Kunden entwickelt und nun im aktuellen Auftrag nur wiederverwendet werden 
und insoweit naheliegenderweise dem Kunden keine ausschließlichen Nutzungs- 



420 Hinweise EVB-IT, 4 mit der Anmerkung, die Rechtsprechung halte eine Obergrenze 
von 10% des Gesamtauftragsvolumens für noch vertretbar, doch dürfe die Obergrenze 
nicht in einem unangemessen kurzen Zeitraum erreicht werden. 

421 BGHZ 21, 107; 88, 382; 92, 168. Es gilt der allgemeine Grundsatz des „pacta sunt ser- 
vanda“. 

422 Dietrich/ Schirra, IT im Unternehmen, 4. 

423 Shipton/Turtschi , Entsprechung und Beweglichkeit als Programm wertorientierter IT- 
Strategie, in: Dietrich/ Schirra, IT im Unternehmen, 13, 22. 
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rechte eingeräumt werden können. Der Kunde wird dann freilich auch nicht den 
Preis für eine komplett ausschließliche Rechteinräumung bezahlen wollen. 

358 Bei der anstehenden Verlängerung von Verträgen kann eine Reduzierung der 
Vergütung durchsetzbar sein, wenn etwa Wartungs-/Pflegeleistungen nicht in 
dem ursprünglich vorausgesehenen Umfang in Anspruch genommen wurden. 
Eine Vergütungsreduzierung lässt sich hier u.a. damit begründen, dass auch die 
Vorhaltekosten des Anbieters (für das Vorhalten qualifizierter Leistung) entspre- 
chend geringer sind. Sinnvoll kann auch das rechtzeitige Einholen von Parallelan- 
geboten sein, um den marktüblichen Preis für eine bestimmte Leistung zum aktu- 
ellen Zeitpunkt festzustellen. Demgegenüber sind mögliche, zuweilen nicht 
unbeträchtliche Migrationskosten zu berücksichtigen, die die Vergütungsdiffe- 
renz übersteigen können. 

359 Meistbegünstigungsklauseln des Vertrages sollten auch in der Laufzeit genutzt 
werden. Hierdurch lassen sich Vergütungsreduzierungen erreichen, wenn anderen 
Kunden des Anbieters für die gleiche Leistung eine niedrigere Vergütung angeboten 
wird. Hier können Kontakte in User Groups für bestimmte Software nützlich sein. 

360 Monatliche Wartungs-/Pflegevergütungen sollten, wenn ein unterschiedlicher 
Tätigkeitsumfang zu erwarten ist, nicht pauschal, sondern grundsätzlich mit Stun- 
dennachweis der Aktivitäten abgerechnet werden. Erhöhungen müssen nicht in 
jeder Höhe akzeptiert werden. Erhöht ein Anbieter nach Abschluss des Wartungs- 
vertrages die Wartungsgebühren um 700%, ist dem Kunden nach § 242 BGB ein 
Lesthalten am Vertrag nicht zumutbar, sondern es besteht insoweit ein Leistungs- 
verweigerungsrecht. 424 

361 Die Anzahl der tatsächlich genutzten Lizenzen sollte genau kontrolliert werden, 
nicht nur, um unzulässiges zusätzliches Vervielfältigen zu verhindern, sondern 
auch, um bei Nichtausschöpfen eines gegebenen Rahmens eine Vergütungsredu- 
zierung zumindest bei Vertragsverlängerungen durchsetzen zu können. 

362 Upgrade-Gebühren haben keine Grundlage im Urheberrecht, wenn sie etwa bei 
einem erforderlichen Hardware- Wechsel für die Systemsoftware berechnet wer- 
den, ohne dass für den Kunden eine zusätzliche oder intensivierte Nutzung mög- 
lich ist. Allerdings ist zu unterscheiden: Hat der Kunde eine direkte Vertragsbe- 
ziehung zum Anbieter der Systemsoftware, kann er aus dem Überlassungsvertrag 
dennoch verpflichtet sein (nämlich mit rein schuldrechtlicher Wirkung), wobei 
bei Vorliegen eines Lormularvertrages aber zu prüfen sein kann, ob der Kunde 
durch eine solche Upgrade- Vergütungsregelung i.S.v. § 307 Abs. 2 BGB unange- 



424 



LG Coburg, Urt.v.29.1.2002 - 22 O 398/01, JurPC Web-Dok. 346/2002. 
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messen benachteiligt wird. Hat der Kunde hingegen über ein Systemhaus erwor- 
ben, das die Systemsoftware selbst zugeliefert erhalten hat, und ist die Upgrade- 
Klausel nicht im Vertrag mit diesem Systemhaus enthalten, kann der Anbieter der 
Systemsoftware mangels V ertragsbezieh ung den Kunden weder aus Urheberrecht 
noch aus Vertrag wirksam in Anspruch nehmen. 

In Service Level Agreements sollten die laufenden Gebühren sowie deren Erhö- 363 
hungen in die Kostenkontrolle und Wirtschaftlichkeitsprüfung einbezogen sein. 

Auch müssen Kündigungsfristen überwacht werden, ebenso die Anzahl der tat- 
sächlich unterstützten Geräte. 425 Überprüft werden sollte, ob Service Levels mit 
sehr hohem Verfügbarkeitsgrad tatsächlich benötigt werde („Premium IT“). 

Bei ERP-Upgrades ist zu beachten, dass mit einem Zuwarten die Migrationskosten 364 
steigen können. Ist die Pflege („Support“) abgelaufen, sollten keine Änderungen 
an der Applikation vorgenommen werden, um unvorhersehbare Auswirkungen 
auszuschließen, wodurch freilich Geschäftsprozesse „eingefroren“ werden, was im 
Wettbewerb von Nachteil sein kann. Eine Erhöhung von Wartungsgebühren bei 
Vertragsverlängerung ist nicht in jedem Fall möglich, sondern nur, wenn der Ver- 
trag ohne Verlängerung das normale Ende seiner Laufzeit erreichen würde. In 
bestehenden Verträgen müssen Preisanpassungsklauseln eingehalten werden. Ein 
Wechsel zu neuen Releases (etwa R/3 Enterprise) kann dann unzumutbar sein, 
wenn hierfür höhere Hardware- und andere Anforderungen erfüllt sein oder vor- 
handene Anwendungen/proprietäre Erweiterungen (z.B. mittels ABAP 4) kosten- 
aufwendig integriert werden müssen, ohne dass der Kunde einen Vorteil in der 
Nutzung zieht. Das Auslaufen der Unterstützung und die Kündigung von War- 
tungs-/Pflegeverträgen ist nicht frei möglich. Entscheidend ist die vereinbarte 
Laufzeit des Vertrages. Die Änderung der Produktpolitik eines Anbieters allein 
rechtfertigt keine außerordentliche Kündigung, 426 ebensowenig die Weigerung 
eines Kunden, bei Rechnerwechsel eine „Upgrade-Gebühr“ in Höhe von (seiner- 
zeit) DM 19.900,00 zu bezahlen. 427 Ordentliche Kündigung bzw. Nichtverlängern 
des Vertrages ist zulässig; eine Verpflichtung des Anbieters, noch fünf Jahre nach 
Ende nach Verkauf des letzten Exemplares (sog. „Life Cycle“) Wartungsleistungen 
verfügbar zu halten 428 , wurde überwiegend kritisiert (s. näher Rdn. 243). Auch 
könnte nur die Verlängerung des Vertrages an sich auf diesem Wege erreicht wer- 
den, nicht eine Stabilität der Vergütungshöhe. 



425 Gadatsch, IT-Controlling, in: Tiemeyer (Hrg.), Handbuch IT-Management, 359, 362. 

426 Zutreffend Welker/Schmidt, CR 2002, 873, 874. 

427 OLG Koblenz, Urt.v.27.5.1993 - 5 U 1938/92, CR 1993, 626 = NJW 1993, 3144. 

LG Köln, Urt.v.16.10.1997 - 83 O 26/97, CR 1999, 218. 



428 
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365 Ein Wechsel auf neue Releases 429 („Punkt-Null- Versionen“) sollte zunächst unter- 
bleiben, da diese meist noch sehr fehlerbehaftet sind, allein schon die laufende 
Fehlerbeseitigung erhebliche zusätzliche Arbeitszeitkosten verursachen kann und 
oft auch alle Anpassungen, Erweiterungen und Schnittstellen mit überarbeitet 
werden müssen. In größeren Unternehmen sollten Releases vereinheitlicht wer- 
den. Elierzu können Verfahren automatischer Software- Verteilung einzusetzen 
sein. 

366 Proprietäre Legacy- Systeme sollten abgelöst werden, wenn ihr Support bzw. stän- 
dige individuelle Anpassungen an Updates laufend hohe Kosten verursacht. All- 
gemein sollten historisch gewachsene „Anwendungslandschaften“ konsolidiert 
und etwa Spezialanwendungen mit niedrigem Beitrag zum Geschäftserfolg durch 
Standardapplikationen ersetzt werden. Server- Konsolidierung zielt darauf ab, 
Dienste, Applikationen und Datenbanken auf wenige, hochverfügbare und dyna- 
misch rekonfigurierbare Systeme zusammenzuführen. 430 Kostenvorteile und eine 
Verbesserung der Datenqualität (Vereinheitlichung der Datenformate, Beseitigen 
von Redundanzen, vereinfachte Zusammenführung) bringt auch eine Konsolidie- 
rung von Datenbanken durch Zusammenlegen. 431 IT- Konsolidierung ist auch 
beim Merger von Unternehmen erforderlich, da hier IT- Abläufe vereinheitlich 
werden können und müssen (um etwa Inkompatibilitäten zu beseitigen) 432 und 
sich Synergien ausschöpfen sowie etwa der Einkauf bündeln lassen. 433 IT- 
Konsolidierung ist als eigenständiges Projekt durchzuführen. Hierbei sind unter 
Berücksichtigung der gesamten Nutzungsdauer Ist- und erwartbare Soll- 
Kostenstruktur zu vergleichen 

367 Sind im Vertragsverlauf öfter Mängelbeseitigungen am System oder mängelbe- 
dingte Updates erfolgt, die jeweils eine Minderung gerechtfertigt haben (§§ 441, 
638 BGB), so kann eine Vergütungsreduzierung im Umfange dieser Minderung 
durchsetzbar sein. Gleiches gilt bei Einschränkungen der Verfügbarkeit von Sys- 
temen. 

368 Verwirkte Vertragsstrafen können als Reduzierung der Vergütung in Anrechnung 
bzw. zum Abzug gebracht werden. 



429 Unter einem „Releasewechsel“ wird meist das Wechseln auf eine höhere Version einer 
Standardsoftware verstanden. Mit dieser Erhöhung werden Fehler entfernt und Leis- 
tungsumfang und/oder -fähigkeit erhöht. 

430 Ehrle/Bukowski, Computerwoche 17/2003, 38. 

431 SprottlFroeber , Computerwoche 25/2003, 40. 

432 Ausf. zur IT-Konsolidierung s. Tiemeyer (Hrg.), Handbuch IT-Management, 99. 

433 Keese/Wehner, IT-Konsolidierung im Rahmen einer Post-Merger-Integration, in: Diet- 
rich/Schirra, IT im Unternehmen, 201, 213. 
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Bei Mängelbeseitigungen muss der Kunde oft eigene Aufwendungen tätigen, die 369 
nicht immer ausreichend in Anschlag gebracht werden, so etwa Personalkosten 
und Kosten aus Unterbrechungen des RZ- bzw. Server-Betriebes, aber auch aus 
dem Prüfen, Dokumentieren und Mitteilen von Mängeln. Diese Kosten sollten 
zumindest schätzweise aufgeschlüsselt und als Abzugspositionen berücksichtigt 
werden, entweder als Vergütungsminderung oder als -reduktion bei Vertragsver- 
längerungen. 

Gleiches gilt sinngemäß für Aufwendungen, die kundenseits erforderlich werden, 370 
weil der Anbieter nur noch eine Folgeversion unterstützt, auf die der Kunde sich 
erst umstellen muss, ohne dass er die zusätzlichen Merkmale aber objektiv benöti- 
gen würde. Einweisungen in Folgeversionen der genannten Art sollten vom An- 
bieter nicht als Leistungen aus Software-Pflege abgerechnet werden. 

Weist die kaufweise überlassene Software bei Übergabe im Test (Funktionsprü- 371 
fung) Mängel auf, ist eine Zurückweisung wegen Vertragswidrigkeit möglich. 434 
Dann ist auch keine Annahme als Erfüllung im Sinne von § 363 BGB erfolgt und 
der Kunde kann bis zur Beseitigung der Vertragswidrigkeit (Mängel) sein Zurück- 
behaltungsrecht aus § 320 Abs. 1 S. 1 BGB an der zu leistenden Vergütung gehend 
machen. Bei größeren Projekten kann bereits der Zinsgewinn deutlich zu Buche 
schlagen. Voraussetzung ist freilich eine Staffelung der Vergütungszahlungen 
dergestalt, dass bei Übergabe noch eine ausreichend hohe Restzahlung offen 
bleibt. 

Das nicht selten vereinbarte „Change Management“ kann begrifflich (kostenfreie) 372 
Mängelbeseitigungen und (kostenpflichtige) Änderungen oder Erweiterungen 
umfassen. Eher sollte eine klare Trennung der Kostenpositionen erfolgen. Fehlt 
zu dem Änderungs-/Erweiterungsteil eine klare Vergütungsregelung und sind die 
Änderungen zugleich als Änderungen des Vertragsgegenstandes anzusehen (z.B. 
Erweiterung der Funktionalität), ist die Vergütung nach dem marktüblichen Maß- 
stab zu berechnen, der deutlich höher hegen kann als der erwartete. Vor der ersten 
Beauftragung mit der Durchführung eines Change Request sollte deshalb unbe- 
dingt die Vergütungsfrage geklärt werden. Die Vergütung kann in der Flöhe zu 
reduzieren sein, wenn nur oder hauptsächlich bereits bei anderen Kunden durch- 
geführte Implementierungen zu übernehmen sind. 

Bei einem Systemwechsel sollten immer auch die „verborgenen“ Migrations- 373 
kosten (etwa für die Altdatenbestände) und die erforderlichen Anpassungen an 
vorgesehene Standardlösungen berücksichtigt werden, ebenso die Kosten der Inte- 
gration einer E-Commerce- Anwendung in vorhandene IT-Systeme. 



434 



Palandt /Heinrichs, Bürgerliches Recht, § 433 Rdn. 41 und 47. 
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374 Soweit der Anbieter sein Haftungsrisiko summenmäßig begrenzt, kann es sinn- 
voll sein, für das nicht abgedeckte Risiko eine Versicherung abzuschließen und 
mit dem Anbieter die Übernahme eines Teils der jeweils vereinbarten, marktübli- 
chen Versicherungsprämie zu vereinbaren. 

375 Vermieden werden sollten schließlich typische Kostenfallen, so etwa 435 

• die schleichende Erweiterung des Projektumfangs. Das Projekt sollte auf Kern- 
anforderungen reduziert werden. „Nice-to-have“-Anforderungen können ge- 
strichen oder zurückgestellt werden. 

• überentwickelte Graphic User Interfaces (GUIs). Die GUI-Entwicklung sollte 
erst erfolgen, wenn ein endgültiges Format feststeht. 

• der Big-Bang-Ansatz des Projekts. Statt eines komplexen Gesamtprojekts soll- 
ten mehrere überschaubare Teilprojekte abgegrenzt werden. 

• extensives Testen. 100% aller Fehler lassen sich nur mit unverhältnismäßigem 
Aufwand (wenn überhaupt) feststellen. Sinnvoll erscheint eine Begrenzung auf 
Kernfunktionalitäten. 

• Mehrfachentwicklungen sollten im auftraggebenden Unternehmen (etwa über 
Projektdatenbanken) erkannt und verhindert werden. 

376 Die angeführten Punkte sind auch bei Unternehmensfusionen zu prüfen, bei de- 
nen eine „IT-Merger-Integration“ durchzuführen ist, um Kostensynergien in der 
Wertschöpfungskette zu erreichen. 436 Kosten lassen sich in diesem Zusammen- 
hang etwa durch Harmonisieren von Geschäftsprozessen und Standardisieren der 
IT- Infrastruktur erreichen. 437 Als Strategien zur Kosteneinsparungen werden ge- 
nannt: 438 

I. Vertragsüberprüfung 

1. Überprüfen und Nachverhandeln aller bestehenden und weiterhin notwendi- 
gen Lieferantenverträge (z.B. Wartung, Consulting). 

2. Umstellen von Verträgen auf Festpreise, soweit möglich. 

3. Sammeln aller einzeln angeschlossenen Lizenzverträge und Bündeln zu Un- 
ternehmens- bzw. Konzernlizenzverträgen unter Abschluss von Rabattverein- 
barungen und Bündelung von ähnlichen Anwendungen verschiedener Liefe- 
ranten zu einem Standard bei einem Lieferanten. 

4. Überprüfen der Möglichkeit des Outsourcens von nicht zur Kernkompetenz 
gehörenden Leistungen. 



435 Nach: ohne Verf., „Schwarze Löcher im Budget“, Computerwoche 36/2004, 26. 

436 Buchtal Eul/Schulte-Croonenberg, Strategisches IT-Management, 72. 

437 Buchtal Eul/Schulte-Croonenberg, Strategisches IT-Management, 145, 152. 

438 Nach Dietrich/ Schirra, IT im Unternehmen, 66, 67. 
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5. Bündeln der Beschaffung von Hardware und ggf. auch Software bei einem 
Lieferanten. 

6. Überprüfen von Asset-Managements, d.h. der Bestandsverwaltung von PCs, 
Druckern, Software. 

7. Überprüfen der Möglichkeit der Reduzierung von Bandbreiten im Netzwerk 
und des Entfallens von Anschlüssen von Arbeitsplätzen an die Netze. 

8. Überprüfen aller laufenden Projekte hinsichtlich Notwendigkeit und Priorität 
sowie Risiken der Termin- und Kosteneinhaltung. 

9. Umstellung von dezentralen Druckern auf Netzwerkdrucker und Einbinden 
von Kopierern in das Gesamtkonzept, Reduzierung von Druckern und evtl. 
Ersatz von teuren Tintenstrahldruckern. 

10. Überprüfen des Output-Managements (Drucken, Faxen und Kopieren) und 
evtl. Ersatz durch seitenbezogene Festpreisangebote. 

11. Anpassen von Leistungsniveaus 

• Reduktion von Endgeräten. 

• Reduktion von eingesetzten Software-Exemplaren. 

• Überprüfen des Lizenzstatus hinsichtlich Raubkopien. 

• Optimieren von Hardware-Kosten (Sinken bei längerer Laufzeit) und Service- 
kosten (Steigen bei längerer Laufzeit). 

• Anpassen von Service Level Agreements an den tatsächlichen Leistungsbedarf. 

• Überprüfen der Auslastung von Netzen (bzw. Bandbreiten). 

• Überprüfen des Nutzungsgrads von Anwendungen und Datenbanken. 

• Differenzierung von Nutzeranforderungen durch Support-Modell (mit unter- 
schiedlichen Preisen für unterschiedliche Leistungen). 

• Identifikation und Reduktion von „Nice-to-have“-Lösungen. 

• Überprüfen von Lizenz- und Wartungsverträgen auf Kündbarkeit. 

• Anmietung/Leasing anstatt Kauf von Hardware. 

Abschließend für diesen Abschnitt ist aber auch zu vermerken, dass Einsparungen 377 
im IT-Bereich das Unternehmen nicht notwendig in jedem Fall profitabler ma- 
chen. 439 Sparen an der IT um jeden Preis kann zulasten der Wettbewerbsfähigkeit 
gehen, wenn das Unternehmen etwa durch das Festhalten an veraltetem Equip- 
ment an Flexibilität verliert. Auch sollte es in der Gesamtperspektive eigentlich 
keine isolierten IT-Projekte geben, sondern nur Projekte, die einen Beitrag zum 
Geschäftserfolg leisten. 440 



439 Shipton/Turtschi , Entsprechung und Beweglichkeit als Programm wertorientierter IT- 
Strategie, in: Dietrich/Schirra, IT im Unternehmen, 13, 23. 

440 Diefn'ch/Schirra, IT im Unternehmen, 49. 
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17. Risiken und Sanierung von IT-Projekten 

a) Risiken 

378 Je größer der Entwicklungs- und/oder Anpassungsteil in IT-Projekten ist, desto 

mehr Risiken bestehen, dass das Projekt Verzögerungen erleidet oder scheitert. 

Angesichts der Vielgestaltigkeit der Projekte lassen sich diese Risiken nur allge- 
mein und nichtabschließend auflisten. Typische Risiken sind etwa: 441 

• Versäumen einer unabhängigen technischen Bewertung des Projektvorschlages 
(u.U. zweites Angebot anderer Firma mit Angabe zur technischen Realisierung 
oder Kurzgutachten einholen). 

• Fehlerhafte Termin- und Aufwandsschätzung. 

• Unrealistische oder nicht ausreichend geklärte Projektziele. 

• Unverbindliche bzw. vom Projektteam nicht akzeptierte Projektpläne. 

• Unvollständige Ermittlung und Festlegung von Anforderungen, keine Erstel- 
lung von Fachkonzept bzw. Feistungsbeschreibung. 

• Kein einheitliches Verständnis der Kundenanforderungen und -erwartungen. 

• Festlegen von Aufwand, Zielvorstellungen, Vorgehen und Zeitplan, bevor der 
Projektinhalt vollständig bekannt ist. 

• Fehlendes oder unvollständiges bzw. widersprüchliches Pflichtenheft. 

• Fehlende oder unklare Vereinbarung über die Modalitäten der Funktionsprü- 
fung (z.B. vorgängige Schulung bzw. Einweisung, Anwesenheit von Vertretern 
beider Vertragsparteien und Führen eines beiderseits zu unterzeichnenden Pro- 
tokolls, Ergänzungsprüfung von Nacherfüllungsarbeiten). 

• Festpreisvereinbarungen ohne Anpassungsmöglichkeiten. 

• Fehlende Ressourcen beim Projektstart. 

• Überschätzen der Feistungsfähigkeit von Standardsoftware, die mehr als erwar- 
tet Anpassungen notwendig macht und zu Kosten- und Terminüberschreitun- 
gen führt. 

• Unterschätzung der Komplexität einer benötigten Fösung. 

• Risiko zu langer Realisierungsphasen, dass Anforderungen sich zwischenzeit- 
lich (mehrfach) ändern („Moving Targets“) oder neue Releases von System- 
software eingeführt werden müssen und hierdurch Anpassungen erforderlich 
werden. 

• Nichtbeachten der Abhängigkeit der Projektphasen voneinander. 

• Unzureichende Durchführung/Kontrolle der einzelnen Phasen. 



441 Teilweise nach: Müller-Hengstenberg , Risikomanagement in DV-Projekten, CR 1999, 
789 £; Streitz, IT-Projekte retten, 70, 163; Schneider/v.Westphalen/ Witzei, Software- 
Erstellungsverträge, F Rdn. 101; Koch, Typische Risiken der Vertragsgestaltung für 
EDV-Projekte, WiB 1997, 178; Hindel/Hörmann/Müller/Schmied, Basiswissen Soft- 
ware-Projektmanagement, 30. 
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• Fehlen von Änderungsverfahren (Change Management). 

• Unzureichende Abnahmeregelungen. 

• Einsatz neuer Technologien ohne Referenzprojekte. 

• Nicht vorhandenes oder unzureichendes Krisenmanagement. 

• Gesamtfestpreis für mehrstufige Projekte mit nicht klar abgegrenztem Leis- 
tungsumfang. 

• Unklar definierte oder unzureichend kontrollierte Kundenmitwirkung, z.B. 
unzureichende Schulung von Mitarbeitern oder unzureichende Aufrüstung 
vorhandener Rechner. 

• Abhängigkeit von verzögert oder schlechterfüllenden Subunternehmern. 

• Unzureichende Qualifikation der beteiligten Mitarbeiter. 

• Unzureichende oder gar fehlende Qualitätssicherung. 

• Unzureichende Strategie für die „Business Continuity“ (Aufrechterhalten des 
Geschäftsbetriebs auch in kritischen Situationen) oder Disaster Recovery (zu 
der etwa automatische Datenspiegelung gehört). 

• Dauer des Parallelbetriebes von Alt- und Neusystem (Altsystem als „Rück- 
griffs“-Möglichkeit, für das aber entsprechend länger Lizenzrechte und War- 
tung/Pflege zu kontraktieren sind). 

• Kostenmäßig nicht klar kalkulierte Migrationsprojekte (etwa von R/3 zu Polge- 
plattformen). 

• Punktionen outsourcen, um sie nicht verstehen zu müssen. 

• Unzureichende Einbeziehung von Mitarbeitern. 

Eine Umfrage der Standish Group im Jahr 2000 ergab beispielsweise, dass nur 28% 379 
der Projekte den versprochenen Leistungsumfang zum geplanten Zeitpunkt, im 
geplanten Budget und mit der spezifizierten Qualität erreichten. 442 Berichtet wird 
außerdem, dass etwa 46% aller Softwareprojekte die Termine bis zu 24 Monaten 
und 59% den Finanzrahmen überschreiten, während 25% der Entwicklungen 
überhaupt scheitern. 443 Kaum Untersuchungen existieren zu der Frage, wie sich 
solche Projekt-“Runaways“ (R. Glass) auf die Wettbewerbsfähigkeit des Kunden 
(und letztlich die Marktpositionierung des Anbieters) auswirken. 

Die Geschäftsleitung muss die oben angeführten typischen Ursachen für ein sol- 380 
ches Scheitern benötigter IT-Projekte rechtzeitig in Betracht ziehen und bereits in 
der Vertragsverhandlungsphase geeignete Vorkehrungen zur Vermeidung eines 
solchen Scheiterns treffen. Geschieht dies trotz des hohen Risikos des Scheiterns 
nicht, kann hieraus eine Haftung der Mitglieder der Geschäftsleitung begründet 
werden. 



442 Zit. nach Coldewey , Warum viele Projekte scheitern, Computerwoche 27/2002, 36. 

443 Müller-Hengstenberg, Risikomanagement in DV-Projekten, CR 1999, 789, 790 m.w.N. 
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Mögliche Schäden können etwa sein: 444 
Auf Kundenseite: 

• Zusätzliche Aufwendungen aufgrund fehlerhafter Leistungen 

• Qualitätsminderung bei Produkten 

• Späterer Eintritt des Nutzens, etwa eines Rationalisierungserfolges 

• Rückabwicklungskosten bei Projektbeendigung (z.B. Verlängerung der Laufzeit 
von Lizenzen und Pflegeverträge für die alte Software) 

Auf Anbieterseite: 

• Zinsverluste durch später erfolgende Zahlungen 

• Vertragsstrafen 

b) Projektsanierung 

381 Soll ein vom Scheitern bedrohtes IT-Projekt vor dem Abbruch gerettet werden, da 
seine Ziele weiter verfolgenswert erscheinen, muss es saniert werden. „Sanieren“ 
meint hier, dass die Ursache für das drohende Scheitern identifiziert, der verblei- 
bende Gestaltungsfreiraum eingeschätzt und das Mögliche realisiert wird, ohne die 
Fehler zu wiederholen. 445 

382 Zunächst muss also die Ursache des drohenden Scheiterns (nach Streitz die „Schief- 
lage“ des Projekts) herausgefunden werden. Als wesentliche Faktoren werden das 
Nichterreichen von Zielen, die mangelnde Akzeptanz durch die Benutzer sowie 
Termin- und Kostenüberschreitungen genannt, 446 wobei freilich vorausgesetzt ist, 
dass überhaupt konkrete Leistungstermine und (Teil-) Vergütungen vereinbart 
sind. Fehlen Terminvereinbarungen, müssen zunächst (angemessene) Leistungs- 
fristen gesetzt werden. Von erheblicher Bedeutung ist aber auch wohl eine unzurei- 
chende Kommunikation zwischen IT- Abteilung und Geschäftsleitung. 447 

383 Die Sanierung eines Projekts sollte mit der Feststellung des erreichten Projektsta- 
tus beginnen. Dieser ist mit den Vorgaben aus dem Pflichtenheft für den Soll- 
Status zu vergleichen, wobei die festgestellten Abweichungen nach ihrem Auswir- 
kungsgrad klassifiziert werden sollten. 448 Wurde bereits mit dem Produktivbetrieb 



444 Nach Streitz , IT-Projekte retten, 167. 

445 Heuscheie, Sanierung von EDV-Projekten, CR 1988, 591. 

446 Heuscheie, a.a.O., 592. 

447 Heuscheie, a.a.O., 592 nennt hier eine „vollkommene Irritation des Managements be- 
züglich der widersprüchlichen und wenig nachvollziehbaren Aussagen der beteiligten 
Projektfachleute“ und ein Sichverschleißen in gegenseitigen Schuldzuweisungen. 

448 Streitz, IT-Projekte retten, 69. 
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begonnen, ist meist der Weg zurück zur ursprünglichen Lösung verbaut, da eine 
Rückmigration der Daten nicht vorgesehen bzw. möglich ist. 449 

Wichtig ist, dass die einzelnen Projektphasen zeitlich und inhaltlich klar vonein- 384 
ander abgegrenzt werden und eine Folgephase erst begonnen wird, wenn die Vor- 
phase beendet und abgenommen ist. 450 Auch sollte die jeweilige Teilvergütung erst 
mit erfolgter Abnahme fällig werden. Hilfsweise kann - bei unberechtigter kun- 
denseitiger Abnahmeverweigerung - der Anbieter eine Fertigstellungsbescheini- 
gung nach § 641 a BGB einholen; diese soll die Abnahme ersetzen, die aber bei 
allen Werklieferleistungen („Lieferung herzustellender beweglicher Sachen“) we- 
gen § 651 BGB nicht mehr erforderlich ist, jedoch weiterhin auch insoweit vertrag- 
lich vereinbart werden kann (und sollte). 

Teil des präventiven Krisenmanagements ist auch, für jede Phase bei deren Schei- 385 
tern eine Alternativlösung („second source“, teilweise auch „double sourcing“ 451 
genannt) festzulegen, etwa Auftragsvergabe an eine Drittfirma (von der gegebe- 
nenfalls bereits ein Angebot vorhegen sollte). Bei Software-Erstellung müssen 
hierzu freilich die Quellcodes verfügbar und transparent (also gut dokumentiert 
und insbesondere kommentiert) sein. Auch sollte der Kunde intern prüfen, in 
welchem Umfang er den vorgegebenen Kostenrahmen maximal überschreiten 
kann (und evtl. Sonderwünsche entsprechend einschränken). 

Soweit durchsetzbar, sollten Vertragsstrafen für das anbieterseitige Überschreiten 386 
von Zeitvorgaben vereinbart werden. Hier muss freilich intern sichergestellt wer- 
den, dass Verzögerungen nicht durch Kundenwünsche verursacht wurden, die der 
Anbieter nicht vorhersehen musste. 

Die Art der Durchführung der Sanierung von Projekten ist ebenfalls wesentlich 387 
von den projektspezifischen Einzelfallumständen abhängig. Auch hier lassen sich 
deshalb nur allgemeine Hinweise geben. Bei einzelnen Projekten behauptet der 
Anbieter die Fertigstellung, während der Kunde diese bestreitet. Hier kann eine 
Konfliktlösung durch (auch außergerichtlich mögliche) Beweissicherung (als 
gerichtliches Verfahren sog. „selbständige Beweissicherung“) erreicht werden, evtl, 
verbunden mit einer Schlichtung. Zunächst ist aber zu klären, ob das aufgetretene 
Problem dem Risikobereich des Kunden oder des Anbieters zuzuordnen ist. Nicht 
selten zeigt sich nämlich, dass das Ausführungshindernis auf Modifikationen zu- 
rückzuführen ist, die etwa die IT- Abteilung des Kunden durchgeführt hat. 



449 Streitz, IT-Projekte retten, 168. 

450 Müller-Hengstenberg, CR 1999, 789, 791. 

451 Klotz/Dorn, Vertragsmanagement in der Informationsverarbeitung, 97. 
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388 Häufig ist die Nichtfertigstellung als solche unstreitig, streitig hingegen die Ursa- 
che. Der Anbieter verweist auf Sonderwünsche des Kunden oder dessen unzurei- 
chende Mitwirkung. Je komplexer das Projekt ist, desto schwieriger wird es für 
den Kunden, von sich aus festzustellen, wann er auf welche Weise mitzuwirken 
hat, wenn dies im Vertrag nicht genau festgelegt ist. Diese Festlegung kann auf- 
grund seiner größeren Erfahrung zumeist eher der Anbieter durchführen; insoweit 
sollte er sich dann aber auch nur in den Fällen auf unzureichende Mitwirkung des 
Kunden berufen dürfen, in denen er diese Mitwirkung klar definiert und angefor- 
dert hat. Dies entspricht seiner Aufklärungs- und Hinweispflicht und ist grund- 
sätzlich der Risikosphäre des Anbieters zuzuordnen. Andererseits wird der Kunde 
damit rechnen müssen, dass alle Erweiterungen oder Änderungen der Leistung 
kostenpflichtige Sonderwünsche sind, die nicht bereits in Vertrag/Leistungsbe- 
schreibung/Pflichtenheft fixiert sind. Diese Modifikationen verteuern nicht nur 
das Projekt, sondern können auch die Verlängerung von Leistungsfristen erforder- 
lich machen, insbesondere, wenn nachträglich in den Code eingegriffen werden 
muss. Insoweit trägt der Kunde das Änderungsrisiko. 

389 Soweit diese Zuordnung selbst streitig bleibt, sollte im nächsten Schritt erst einmal 
der erreichte Leistungsstand festgestellt und gemeinsam verbindlich protokolliert 
werden. Von diesem aus ist dann zu prüfen, mit welchem (Zusatz-)Aufwand das 
Projektziel in welcher Zeitdauer erreichbar ist. Der Kunde muss zusätzlich prüfen, 
ob die festgestellten Leistungsmängel derart gravierend sind, dass eine weitere 
Leistungserbringung durch diesen Anbieter für den Kunden nicht mehr zumutbar 
ist. In diesem Fall ist weiter zu prüfen, ob es kostengünstiger ist, eine Drittfirma 
mit der Weiterentwicklung („auf der Projektruine“) oder gleich mit einer voll- 
ständigen Neuentwicklung zu beauftragen; immerhin erfordert die vorgängige 
Prüfung des vorhandenen Codes durch eine Drittfirma selbst oft erheblichen Kos- 
ten- und Zeitaufwand. 

390 Erscheint die Fortführung der Entwicklung durch den bisherigen Anbieter als 
vertretbar (oder gibt es keine Mitbewerber), sollte diese vertraglich neu definiert 
werden. Hier sollten jetzt unbedingt kontrollfähige kleinere Leistungsabschnitte 
definiert und mit Abnahme/ Vergütung bzw. Vertragsstrafenverwirkung ver- 
knüpft werden (Milestones). Bei diesen Teilabnahmen können/sollten Dritte 
(Sachverständige etc.) hinzugezogen werden. Zugleich ist ein Vorbehalt zu erklä- 
ren, dass die Wirkung der Teilabnahme entfällt, wenn der Integrationstest fehl- 
schlägt. Bei Stundensatzhonoraren sollte die Obergrenze der zulässig in Rechnung 
zu stellenden Anzahl der Stunden festgelegt sein. Mindestens ein Drittel der Ver- 
gütung sollte erst als Schlusszahlung bei Gesamtabnahme/Integrationstest fällig 
werden. Auch sollte eine Vertragsstrafe für den Fall weiterer Vertragsverletzungen 
vereinbart werden, aber durch Individualvertrag. Alternativ sollte anbieterseits 
eine Erfüllungsbürgschaft vorgelegt werden. Weiter ist zu klären, ob der Auftrags- 
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umfang - jedenfalls temporär - auf die wichtigsten Teile des Projektes reduziert 
werden kann, soweit diese trennbar sind. Leistungstermine sollten nach Möglich- 
keit als Fixtermine vereinbart werden. Ist dies nicht möglich, lässt sich ersatzweise 
eine bindende Leistungsfrist vereinbaren, bei deren ergebnislosem Ablauf der 
Kunde sofort zurücktreten oder Nichterfüllungsansprüche geltend machen kann. 

Von der Werkabnahme unabhängige Abschlagszahlungen können auch noch 391 
nach Vertragsschluss vereinbart werden (etwa bei längerdauernden Funktionsprü- 
fungen). 452 

Manches Projekt kann durch eine Reduzierung des Projektumfangs gerettet wer- 392 
den. 453 Dies kann etwa durch Verzicht auf nicht zwingend erforderliche Anpas- 
sungen oder bestimmte organisatorische Veränderungen erreicht werden. 454 Hier- 
zu kann auch ein stärkeres Strukturieren von abzubildenden Geschäftsprozessen 
in Richtung Standards gehören, um individuelle Anpassungen oder Ergänzungs- 
programmierungen unnötig zu machen. Auch ein Zentralisieren der Datenhal- 
tung ist vorteilhaft. Kostenintensive eigene „EDV-Inseln“ sollten möglichst aufge- 
geben und deren Aufgaben auf Dienstleister übertragen werden. Weiter ist an eine 
Aufteilung in eigenständige, zeitlich verschiebbare Projektteile zu denken. 

Teilweise finden sich in Verträgen rudimentäre Bestimmungen zu einem „Eskala- 393 
tionsmanagement“. Diese Regelungen helfen dann wenig, wenn nur festgestellt 
wird, dass die Vertragsparteien „einen fairen Kompromiss herbeiführen“ sollen. 

Das ergibt sich im Grunde schon aus § 242 BGB, wonach der Schuldner die Leis- 
tung so bewirken soll, wie Treu und Glauben es mit Rücksicht auf die Verkehrssit- 
te erfordern. Einzelne Anbieter versuchen eine Konkretisierung, indem sie zu 
berücksichtigende Faktoren benennen, etwa die „Realisierbarkeit innerhalb des 
gemeinsam verabschiedeten und fortgeschriebenen Zeitplans“, den „Grad der 
Unabweisbarkeit einer Anforderung“, die „Verfügbarkeit einer bereits vorhande- 
nen oder schneller realisierbaren und zumutbaren Lösung“ bzw. der „Einfluss der 
fraglichen Systemeigenschaft auf Wartungsfreundlichkeit und zu erwartende Per- 
formance“, wie in einem ERP- Vertrag eines großen Anbieters formuliert wurde. 
Formuliert sind hier aber eben nur Anhaltspunkte, jedoch weder eine mögliche 
Konfliktlösung noch auch nur ein Weg zu dieser. Die Vereinbarung eines Eskala- 
tionsmanagements (EM) darf insbesondere nicht dazu führen, dass der Kunde an 
sich bestehende Erfüllungs- und/oder Gewährleistungsansprüche nicht mehr 
geltend machen kann. Dies widerspräche schon den §§ 307 Abs. 2 Nr. 2 bzw. 309 
Nr. 8 a) BGB. Besonders ist zu beachten, dass der Kunde auch nicht durch nach- 



452 BGH, Urt.v. 29.1.2002 - X ZR 231/00, JurPC Web-Dok. 168/2002. 

453 Streitz, IT-Projekte retten, 170. 

454 Streitz, IT-Projekte retten, 170. 





134 



B. Stufen der Durchführung von IT-Projekten 



trägliche individualvertragliche Vereinbarung im EM auf diese Rechte verzichtet. 
Weiter sollte die Regelungskompetenz nicht einseitig beim Anbieter hegen (der 
sonst festlegen könnte, wann welche Leistung von ihm erbracht wird); vielmehr 
muss eine tatsächliche Einigung erfolgen. Dies ist im Vertrag bzw. Ergänzungs- 
/Sanierungsvertrag festzuhalten, da das EM sonst als einseitiges Leistungsbestim- 
mungsrecht des Anbieters nach § 315 BGB ausgelegt werden könnte. 

394 Auch bei Vertragsverlängerungen (etwa von Software-Pflegeverträgen) kann das 
Einholen mehrerer Angebote die Verhandlungsposition des Kunden stärken und 
ihm helfen, Preisreduzierungen zu erreichen. Allgemein ist ein Vertragsmanage- 
ment sinnvoll, in dem regelmäßig die jeweiligen Leistungspflichten (im Vergleich 
zum aktuell benötigten Leistungsumfang), Vertragslaufzeiten und Ausstiegsklau- 
seln überprüft werden. 

395 Vertragsmanagement und Durchführungs-Controlling sind originäre Aufgabe 
und Pflicht der Geschäftsführung (§§ 93 Abs. 1, 91 Abs. 2 AktG, 43 Abs. 1 
GmbHG). 




C Rechte des Software-Anwenders bei Insolvenz des Anbieters 



Wird der Anbieter von Software insolvent, kann dies die weiteren Nutzungsmög- 396 
lichkeiten der Anwender dieser Software erheblich reduzieren oder gar völlig auf- 
heben. Die verschiedenen Anbieterleistungen - nämlich insbesondere kaufweise 
Überlassung, Vermietung und Pflege von Software - weisen hier ein unterschied- 
liches „Risikoprofil“ auf. Dieses ist nachfolgend kurz zu erläutern. 

Die Geschäftsleitung muss die Risiken einer Insolvenz beauftragter Anbieter vor 397 
Vertragsabschluss konkret prüfen, also feststellen, welche Software von welchem 
Anbieter stammt und welche Folgen eine mögliche Beendigung der Zulässigkeit 
der Nutzung dieser Software für das anwendende Unternehmen hat. Schließlich 
sollte aufgelistet werden, für welche der eingesetzten Applikationen auf Software 
anderer Anbieter ausgewichen werden kann. Mit diesen Anbietern sollte für Soft- 
ware, deren „Ausfall“ bestandswesentliche Funktionen oder Abläufe des Unter- 
nehmens gefährden würde, schon vorsorglich eine Bereithaltungsvereinbarung 
geschlossen werden. 

Bei Anbieterinsolvenz fällt das jeweils bestehende Vertriebsrecht des Anbieters an 398 
der Software in die Insolvenzmasse. Die Software selbst ist Teil der Insolvenzmasse 
des Anbieters (§ 35 InsO) und unterliegt der Verfügungsbefugnis des Insolvenz- 
verwalters (§ 80 InsO). Erfasst werden jeweils Datenträger und Dokumentatio- 
nen 1 . Das Urheberrecht an Computerprogrammen unterliegt als höchstpersönli- 
ches und nichtübertragbares Recht (§ 29 S. 2 UrhG) im Gegensatz zu den 
Verwertungsrechten aus ihm nicht der Vollstreckung (§ 857 Abs. 1 i.V.m. 851 
Abs. 1 ZPO). 

Soweit die softwarebezogenen Verträge gegenseitig und beiderseitig noch nicht 399 
voll erfüllt sind, ist die Insolvenzmasse nicht zur restlichen Erfüllung verpflichtet, 
kann der Insolvenzverwalter diese aber wählen (§ 103 InsO). Maßgebliches insol- 
venzrechtliches Kriterium für die Wahlentscheidung des Verwalters ist, ob eine 
weitere Leistungserbringung zu einem Anspruch der Masse auf eine (weitere) 
Gegenleistung gegen den Anwender als Vertragspartner führt. 2 Ein solcher An- 



1 Kammei , Software in der Insolvenz, Rdn. 8 

2 S. näher Hoeren/Sieber/Koch, Handbuch Multimedia Recht, Kap. 26.1 Rdn. 11. 
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Spruch ist ausgeschlossen, wenn der Vertragspartner seine Leistung bereits voll 
erbracht (z.B. eine Erstellungsvergütung voll bezahlt) hat. Hat der Vertragspartner 
aber selbst noch nicht alle Leistungen erbracht (z.B. zukünftige Mietzinszahlungen 
noch nicht geleistet), ist der Insolvenzverwalter berechtigt (aber nicht verpflich- 
tet), nach § 103 InsO die (restliche) Erfüllung des Vertrags zu wählen. Trifft der 
Verwalter trotz Aufforderung durch den Vertragspartner keine Wahl, kann dieser 
nicht auf Erfüllung bestehen (§ 103 Abs. 2 InsO). 



400 püj- die Nutzungspraxis der betroffenen Anwender ist nun folgender Grundsatz 
wesentlich: Der Kunde bleibt auch nach Eröffnung des Insolvenzverfahrens 
berechtigt, seine ihm überlassenen Programmexemplare weiter zu nutzen, 
muss die Nutzung also keineswegs sofort einstellen, da die Eröffnung des Insol- 
venzverfahrens den gegenseitigen Überlassungsvertrag nicht umgestaltet, son- 
dern die Software-Lizenz fortbestehen 3 und die Wirksamkeit des Vertrages un- 
berührt lässt. 4 Dies gilt auch dann noch, wenn der Insolvenzverwalter die Wahl 
trifft, den Vertrag nicht weiter zu erfüllen. 5 Im Vertragsverhältnis bestehen viel- 
mehr wechselseitig Nichterfüllungseinreden, die nur zur zukünftigen Nicht- 
durchsetzbarkeit der Ansprüche auf (noch zu erbringende) Gegenleistungen 
führen, weshalb (weitere) Erfüllungsansprüche (etwa auf restliche Lieferung oder 
auf Pflegeleistung) nicht mehr durchgesetzt werden können. 6 



401 Regelungszweck des § 103 InsO ist, dass die Insolvenzmasse nicht zu einer Leis- 
tung ohne Gegenleistung verpflichtet werden soll, da sich hierdurch die Masse 
verringern könnte. Die Wahl der Vertragserfüllung soll also ermöglichen, noch 
ausstehende Leistungen des Vertragspartners zu erlangen, auf die die Masse ohne 
Erfüllungswahl keinen Anspruch hätte. 7 Andererseits soll der Vertragspartner 
seine noch ausstehende Leistung nicht erbringen müssen, wenn er hierfür nur eine 
Gegenleistung aus der Quote erhält. 8 Allerdings kann der Verwalter nur Erfüllung 
oder Nichterfüllung in Bezug auf den ganzen Vertrag wählen; er kann also nicht 
für einzelne Vertragsteile Erfüllung wählen und für andere die Erfüllung ableh- 
nen. 9 Der Insolvenzverwalter muss vor Ausübung des Wahlrechts in betriebswirt- 
schaftlich-technischer Hinsicht prüfen, ob nach den Umständen des Einzelfalls, 



3 BGH, Urt.v. 25.4.2002 - IX ZR 313/99, NJW 2002, 2783 zu Ansprüchen aus Bauvertrag; 
ausführlich s. Berger, CR 2006, 505, 507; Hoeren/Sieber/Koch, Handbuch Multimedia 
Recht, Kap. 26.1 Rdn. 28. 

4 Abel, NZI 2003, 121, 124. 

5 BGH, Urt.v.17.1 1.2005- IX ZR 162/04, CR 2006, 151. 

6 Kammei, Software, in der Insolvenz, in: Kilian/Heussen, Computerrechtshandbuch, 
Lieferung 18, Rdn. 79. 

7 MünchKommlnsO-Kre/i, § 103 Rdnr. 2. 

8 Wandtke/Bullinger, Praxiskommentar zum Urheberrecht, §§ 103,105,108 InsO,Rdnr.2. 

9 Loewenheim/Kreuzer/Reber, Handbuch des Urheberrechts, § 95 Rdnr. 65. 
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insbesondere nach dem jeweiligen Projektstatus, durch die Masse überhaupt noch 
eine Leistung erbracht werden soll und kann (also auf ausreichend qualifizierte 
Entwickler und Arbeitsmittel zurückgegriffen werden kann) und die vertraglich 
erzielbare Gegenleistung durch den Vertragspartner den Aufwand für die eigene 
Leistungserbringung zumindest abdeckt. 

Wurden beiderseitig überhaupt noch keine Vertragsleistungen erbracht, besteht 402 
kein durchsetzbarer Anspruch des Vertragspartners gegen die Masse auf Vertrags- 
erfüllung und kann auch die Masse keinen Erfüllungsanspruch gegen den Ver- 
tragspartner durchsetzen. 10 Der Insolvenzverwalter kann aber auch hier Erfüllung 
wählen, 11 wenn die Erfüllung der Masse eine Gegenleistung zuführt. 

Bei beiderseitig noch nicht oder jedenfalls noch nicht vollständig erfüllten Ver- 403 
trägen hat der Insolvenzverwalter das Recht zu wählen, ob er den Vertrag 
(rest)erfüllt (§ 103 InsO) oder nicht. Wählt er die Vertragserfüllung (die sich be- 
grifflich aus § 362 BGB herleitet), richten sich fortbestehende vertragliche Ansprü- 
che des Kunden gegen die Insolvenzmasse und liegt also eine - vorweg zu berich- 
tigende (§ 53 InsO) - Masseverbindlichkeit vor (§ 55 Abs. 1 Nr. 2 InsO). 12 Die 
Masse erhält ihrerseits eine Masseforderung gegen den Kunden (meist auf Vergü- 
tungszahlung) . Die Erfüllungswahl begründet die Erfüllungsansprüche der Masse 
und gegen die Masse neu. 13 Sie wirkt wie ein Neuabschluss des Vertrags mit iden- 
tischem Inhalt. 14 Da der Vertrag damit unverändert fortbesteht, kann der Verwal- 
ter den Inhalt des Vertrages nicht einseitig ändern, also z.B. nicht zusätzliche Nut- 
zungseinschränkungen in den Vertrag einführen. 

Bei Wahl der Nichterfüllung durch den Insolvenzverwalter bleibt der Vertrag 404 
ebenfalls bestehen, wird er aber rein insolvenzmäßig abgewickelt, 15 jedoch nur, 
wenn der Kunde Schadensersatzansprüche aus Nichterfüllung gegen die Masse 
geltend macht und hierzu entsprechende Erklärungen wie die Forderungsanmel- 
dung abgibt. Die bloße verwalterseitige Erfüllungsablehnung führt als solche also 
noch nicht zur Begründung von Ersatzansprüchen. 16 



10 MünchKommlnsO-Kre/t, § 103 Rdnr. 3, 18; Hoeren/Sieber/Koch, Handbuch Multime- 
dia Recht, Kap. 26.1 Rdn. 15. 

11 MünchKommlnsO-Kre/t, § 103 Rdnr. 39. 

12 MünchKommlnsO-Kreyt, § 103 Rdnr. 3. 

13 MünchKommlnsO-Kre/t, § 103 Rdnr. 13. 

14 MünchKommlnsO-Kre^f, § 103 Rdnr. 4L 

15 BGHZ 89, 189, 194; BGH WM 1984, 265; MünchKommlnsO-Kre/f, § 103 Rdnr. 13: 
Hoeren/Sieber/Koch, Handbuch Multimedia Recht, Kap. 26.1 Rdn. 19. 

Bärenz, NZI 2006, 72. 



16 
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1. Software-Kauf 

405 Die Käufer von Software bleiben auch bei Insolvenz des Anbieters Eigentümer der 
erworbenen Software und zu deren Nutzung berechtigt. Zukünftige Unterstüt- 
zungsleistung wie zukünftige Updates oder der weitere Betrieb eines Help Desks 
für Nutzer können aber nicht erwartet werden. 17 

406 Erwirbt der Kunde Software kaufweise, so ist dieser Vertrag insolvenzrechtlich von 
beiden Seiten erfüllt, wenn der Anbieter das Programmexemplar überlassen und 
der Kunde den Kaufpreis bezahlt hat. Dieser beiderseits erfüllte Vertrag bleibt von 
der Eröffnung des Insolvenzverfahrens unberührt; er ist insolvenzfest. Der Insol- 
venzverwalter hat hier kein Wahlrecht aus § 103 InsO. 18 Er kann also weder Rück- 
gabe noch Löschung des überlassenen Programm- oder sonstigen Werkexemplares 
und nicht einmal Beendigung der Nutzung verlangen, wenn das Recht zur Nut- 
zung zeitlich unbeschränkt und gegen Einmalvergütung, also kaufweise, einge- 
räumt wurde. Auch der vor Verfahrenseröffnung erfolgte Übergang von dingli- 
chen Rechten kann durch den Verwalter nach Verfahrenseröffnung nicht durch 
Wahl der Nichterfüllung des zugrundeliegenden Vertrages verhindert werden, 19 
was zur Folge hat, dass dinglich wirkende Nutzungsrechte insoweit insolvenzfest 
sind. 

407 Wenn hingegen der Anbieter den Vertrag bei Eintreten des Insolvenzfalles noch 
nicht voll erfüllt, also etwa noch nicht geliefert, und der Kunde bei Kauf eine Rest- 
rate noch nicht bezahlt hat, steht dem Insolvenzverwalter des Anbieters das Wahl- 
recht aus § 103 InsO zu. Allerdings endet auch hier (entgegen früherer Rechtspre- 
chung) die Nutzungsbefugnis des Kunden nicht im Zeitpunkt der Eröffnung des 
Insolvenzverfahrens. Der BGH stellte ausdrücklich klar, 20 dass die Verfahrenser- 
öffnung den gegenseitigen Vertrag, hier also den Kaufvertrag, nicht materiell- 
rechtlich umgestaltet, sondern wegen der beiderseitigen Nichterfüllungseinreden 
der Vertragspartner (§ 320 BGB) nur zur Nichtdurchsetzbarkeit der (fortbeste- 
henden) vertraglichen Ansprüche auf (noch zu erbringende) Gegenleistungen 
führe. Demzufolge besteht der Software-Überlassungsvertrag fort und der Kunde 
darf die Software weiter nutzen, soweit er hierzu nicht einen Erfüllungsanspruch 



17 Berger, CR 2006, 505, 507. 

18 Kammei, Software in der Insolvenz, in: Kilian/Heussen, Computerrechts-Handbuch, 
18. Ergänzungslieferung, Kap. 171 Rdnr. 77; Redeker, ITRB 2005, 263, 264. 

19 BGH, Urt.v. 17.11.2005 - IX ZR 162/04, NJW 2006, 915 für Nutzungs- und Vertriebs- 
rechte an Software. 

20 BGH, Urt.v. 25.4.2002 - IX ZR 313/99, NJW 2002, 2783 = NZI 2002, 375 = ZIP 2002, 
1093 = BGHZ 150, 353 zu Ansprüchen aus Bauvertrag. 
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durchsetzen muss 21 . Für die reine Fortsetzung der Nutzung der Software durch 
den Kunden auf dessen System ist nämlich keine Erfüllungshandlung seitens der 
Masse erforderlich. Das Nutzungsrecht erlischt nicht, da der Überlassungsvertrag 
gerade nicht (und schon gar nicht rückwirkend) umgestaltet wird 22 , sondern fort- 
besteht. Eine Ausnahme gilt dem BGH zufolge jedoch für Ansprüche der Masse 
gegen den Vertragspartner auf Gegenleistung für masseseits vor Verfahrenseröff- 
nung erbrachte Leistungsteile; insoweit bleiben die Erfüllungsansprüche der Masse 
durchsetzbar. 23 

2. Software-Erstellung 

Auch bei Werkvertragsrecht folgenden Erstellungsverträgen ist entscheidend, ob 408 
der Vertrag beiderseitig noch nicht vollständig erfüllt wurde. Nur dann besteht das 
Wahlrecht des Insolvenzverwalters aus § 103 InsO. 24 Er darf Vertragserfüllung 
wählen, wenn die aus der Entwicklung erlösbare Vergütung die noch zu erbrin- 
gende Entwicklungsleistung finanzieren wird. In diesem Fall ist der hierdurch 
entstehende Kundenanspruch vorweg zu befriedigende Masseverbindlichkeit 
(§§ 53, 55 Abs. 1 Nr. 2 InsO) 25 . 

3. Vermietung von Software 

Bei mietweiser Überlassung ist die Nutzung der Software zeitlich begrenzt einge- 409 
räumt. Mietverträge sind - zumindest für Verlängerungszeiträume - beiderseitig 
noch nicht voll erfüllt. Für den erfüllten Teil des Vertrages wird eine Erfüllungs- 
wahl als nicht möglich angesehen, da deren Ziel, eine Gegenleistung des Vertrags- 
partners für die Masse zu erwerben, insoweit nicht erreicht werden kann, 26 
sondern vielmehr Erfüllung nach § 362 BGB eingetreten ist. 27 Für die noch aus- 
stehenden Leistungen (etwa weitere Mietzinszahlung gegen weitere Überlassung) 



21 Kammei, Software, in der Insolvenz, in: Kilian/Heussen, Computerrechts-Handbuch, 
Lieferung 18, Rdnr. 79. 

22 BGH NJW 2002, 2783, 2785; allgemein MünchKommlnsO-Kre/t, § 103 Rdnr. 3, 18. 

23 BGH NJW 2002,2783, 2785. 

24 Paulus, Software in der Vollstreckung, C. Insolvenz, in: Lehmann (Hrg.), Rechtsschutz 
und Verwertung von Computerprogrammen, XVII Rdnr. 71 (für Software-Erstellungs- 
verträge). 

25 Kammei, a.a.O., Rdnr. 80. 

26 MünchKommlnsO-Kre/t, § 103 Rdnr. 47. 

27 Loewenheim/Kreuzer/Reber, Handbuch des Urheberrechts, § 95 Rdnr. 83. 
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ist Erfüllungswahl möglich, da hier der Masse bei Leistungserbringung aus dieser 
noch Gegenleistungen zufließen können. 28 

4. Pflege von Software 

410 Ähnlich wie Mietverträge bedürfen auch Software-Pflegeverträge grundsätzlich 
der Verlängerung bzw. der Prüfung, ob eine ordnungsgemäße Kündigung erfolgen 
soll. Der Insolvenzverwalter muss dies im Rahmen seines Wahlrechts prüfen. Der 
Insolvenzverwalter wird Vertragserfüllung, soweit eine Wahl zulässig ist, nur wäh- 
len, wenn die Erbringung der erforderlichen Pflegeleistungen zumindest bis zum 
nächsten Kündigungstermin insbesondere auch personell gesichert ist. 29 Bei Ab- 
lehnung der Vertragserfüllung erhält der Kunde keine weiteren Pflegeleistungen. 
Vielmehr sind die wechselseitigen Forderungen zu saldieren und der Kunde muss 
einen sich zu seinen Gunsten ergebenden Saldo zur Tabelle anmelden (§ 103 
Abs. 2 S. 1 InsO). 30 



28 MünchKommlnsO-Kre/f, § 103 Rdnr. 47. 

29 Kammei, Software, in der Insolvenz, a.a.O. Rdnr. 103. 

30 Kammei, Software, in der Insolvenz, a.a.O., Rdnr. 104; Hoeren/Sieber/Koc/i, Handbuch 
Multimedia Recht, Kap. 26.1 Rdn. 45. 




D IT-Sicherheitsmanagement als Projekt 



Die Sicherheit von betrieblichen IT-Systemen ist unverzichtbar, können doch 411 
systeminterne Störungen und mehr noch Angriffe von außen die Systemnutzung 
empfindlich beeinträchtigen oder unterbrechen und hierdurch sogar bestandsge- 
fährdende Betriebsunterbrechungen verursachen. IT-Sicherheit muss deshalb als 
wesentliches Leistungsmerkmal für die Implementierung jedes neuen Systems 
betrachtet werden. Zugleich ist es Pflicht der Geschäftsleitung des anwendenden 
Unternehmens, bei Erwerb bzw. Eigenerstellung des Systems wie bei laufender 
Unterstützung von dessen Anwendung die erforderliche Sicherheit herstellen und 
aufrechterhalten zu lassen. 

Es empfiehlt sich, die Herstellung und laufende Unterstützung der IT-Sicherheit 412 
als Projekt oder Teil eines Projekts zu definieren und als solches in der Durchfüh- 
rung zu kontrollieren. Ein solches „Projekt IT-Sicherheit“ kann allerdings nicht 
wie andere IT-Projekte, etwa die Einführung von unternehmenssteuernder Soft- 
ware, auf eine begrenzte Zeitdauer angelegt werden, sondern muss während der 
gesamten vorgesehenen Nutzungsdauer von Software und Systemen durchge- 
führt werden. Auf Anbieter kann die entsprechende Aufgabenerfüllung durch 
Festlegen geschuldeter sicherheitsbezogener Leistungsmerkmale des zu implemen- 
tierenden Systems und dessen laufender Wartung und Pflege übertragen werden. 
Zumindest die Kontrolle der Erfüllung dieser Aufgabe liegt aber immer auch beim 
auftraggebenden Kunden. Im Rahmen des Projektvertrags mag hier eine bloße 
Obliegenheit des Auftraggebers zu sehen sein. Sie ist aber immer dann mit beson- 
deren Sicherungspflichten des Auftraggebers verbunden, wenn Dritte, etwa Kun- 
den, Mitarbeiter oder andere Beteiligte (z.B. Nutzer im Internet) durch unsichere 
(z.B. virenverseuchte) IT-Systeme gefährdet werden. IT-sicherungspflichtig ist der 
Anbieter dann, wenn er im Wege von Outsourcing 1 bzw. Application Service Pro- 
viding 2 betriebliche IT- Abläufe übertragen erhält. 

IT-Sicherheitsmanagement ist (an IT-Leiter delegierbare) Aufgabe der Geschäfts- 413 
leitung. Diese muss beachten, dass Sicherheitslücken in der Wertschöpfungskette 
den Unternehmenserfolg bedrohen und sogar existenzgefährdend sein sowie zur 



1 Zu Outsourcing s. Rdn. 547 ff. 

2 Zu Application Service Providing s. Rdn. 581 ff. 
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Bedrohung von Rechtsgütern Dritter werden können. 3 Bestandssicherung des 
Unternehmens und Rechtsgüterschutz sind damit untrennbar mit der Sicherheit 
der betrieblichen IT verbunden. 

414 „Gelebte IT- Sicherheit“ im Betrieb bringt neben der Erfüllung des eigentlichen 
Schutzzwecks verschiedene weitere Vorteile auch für die Unternehmensleitung 
mit sich, so etwa verantwortungsbewusstes Handeln und Identifikation der Mitar- 
beiter mit den Unternehmenszielen, Vertrauen bei Geschäftspartnern und hieraus 
Wettbewerbsvorteile sowie kürzere Dauer von Wartungsarbeiten an gut administ- 
rierten IT-Systemen. 4 Auch kann das eigene „proaktive“ Mitwirken von Betriebs- 
räten und Arbeitnehmern (z.B. Systemverwaltern) wesentlich zur Verbesserung 
des Sicherheitsstatus der betrieblichen EDV beitragen. 



1. Grundbegriffe des IT-Sicherheitsmanagements 

415 „Sicherheit in der Informationstechnik“ (IT) wird gesetzlich als „die Einhaltung 
bestimmter Sicherheitsstandards“ definiert, „die die Verfügbarkeit, Unversehrtheit 
oder Vertraulichkeit von Informationen betreffen“. Diese Einhaltung erfolgt 
„durch Sicherheitsvorkehrungen 

1. in informationstechnischen Systemen oder Komponenten oder 

2. bei der Anwendung von informationstechnischen Systemen oder Komponen- 
ten“ (§ 2 Abs. 2 BSIG) 5 . 

Die verwendeten Begriffe werden in der folgenden Weise näher bestimmt: 

• „Verfügbarkeit“ umfasst den Schutz von Informationen vor Verlust, Entzug, 
Blockade oder Zerstörung, 6 



3 Schneider/v.Westphalen/Pefer, Software-Erstellungsverträge, G Rdn. 26. 

4 Bundesamt für Sicherheit in der Informationstechnik (BSI), Leitfaden IT-Sicherheit - 
IT-Grundschutz kompakt, verfügbar unter www.bsi.bund.de, 6. 

5 Gesetz über das Bundesamt für die Sicherheit in der Informationstechnik (BSIG). All- 
gemeiner ist die Definition von „Datensicherheit“ in DIN 44300 als „Sachlage, bei der 
Daten unmittelbar oder mittelbar soweit wie möglich vor Beeinträchtigung bewahrt 
sind, und zwar unter Berücksichtigung verarbeitungsfremder Risiken wie auch im Ver- 
lauf auftrags- und ordnungsgemäßer Erbringung einer Datenverarbeitungsleistung. 
Daten dürfen also weder bei datenverarbeitenden Prozessen oder auftragsbedingten 
Vor- und Nacharbeiten noch in Funktionseinheiten zur Abwicklung auftragsbedingter 
Arbeiten noch durch Handeln von an auftragsbedingten Arbeiten beteiligten Personen 
beeinträchtigt werden.“ 

6 Heckmann , MMR 2006, 280, 281 m.w.N. 
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• „Unversehrtheit“ den Schutz vor jeglicher Form ungewollter Informationsver- 
änderung , 7 und 

• „Vertraulichkeit“ den Schutz vor Informationsausspähung . 8 

2. Durchführen des IT-Sicherheitsprozesses als Aufgabe der Leitungsebene 
(IT-Sicherheitsmanagement) 

Genuine Aufgabe der Geschäftsleitung ist es, gegen typische (d.h. erwartbare) 416 
Gefährdungen von IT- Anwendungen angemessene Vorkehrungen zu treffen und 
hierbei ein Mindestschutzniveau einzuhalten. Ein Mindestschutzniveau erfordert 9 
übergreifende Regelungen zur IT-Sicherheit und Maßnahmen wie etwa die Festle- 
gung und Zuweisung von verantwortlichen Personen für einzelne IT-Objekte 
(z. B. Anwendungen, IT-Komponenten). 

Als typische Gefährdungen gelten 10 neben höherer Gewalt (Feuer, Wasser, unzu- 417 
lässige Temperatur und Luftfeuchte) organisatorische Mängel (fehlende oder un- 
zureichende Regelungen, unzureichende Kenntnis über vorhandene Regelungen, 
fehlende, ungeeignete, inkompatible Betriebsmittel, fehlende oder unzureichende 
Wartung, unbefugter Zutritt zu schutzbedürftigen Räumen, unerlaubte Ausübung 
von Rechten und unkontrollierter Einsatz von Betriebsmitteln), menschliche Fehl- 
handlungen, technisches Versagen (Ausfall der Stromversorgung, interner Ver- 
sorgungsnetze oder vorhandener Sicherungseinrichtungen) und vorsätzliche 
Handlungen. 

Die Geschäftsleitung muss den IT-Sicherheitsprozess initiieren, steuern und 418 
kontrollieren, damit dieser im Unternehmen in allen Bereichen umgesetzt wird . 11 
Weiterhin muss die Leitungsebene 

• ein IT- Sicherheitskonzept erstellen , 12 

• einen kontinuierlichen IT-Sicherheitsprozess etablieren und dokumentieren , 13 

• eine für die jeweilige Institution passende IT -Sicherheitsstrategie festlegen , 14 



7 Heckmann, a.a.O., 281 

8 Heckmann, a.a.O., 281,282. 

9 GS-Handbuch, B 1.1. 

10 Grandschutzhandbuch des Bundesamtes für Sicherheit in der Informationstechnik 
(BSI), nachfolgend kurz: GS-Handbuch, B 1.1. 

11 GS-Handbuch, hier M 2.336. 

12 GS-Handbuch, M 2.195. 

13 GS-Handbuch, M 2.201 (C). 

14 GS-Handbuch M 2.335. 




144 



D. IT-Sicherheitsmanagement als Projekt 



• hierfür wie für alle weiteren Sicherheitsfragen eine Person als Hauptverantwort- 
lichen benennen, die dafür zuständig ist, eine geeignete Organisationsstruktur 
für IT-Sicherheit aufzubauen und aufrechtzuerhalten 15 und vorab, als eine der 
ersten Aktionen, 

• eine IT-Sicherheitsleitlinie erstellen. 16 

• im laufenden Betrieb die IT-Sicherheit aufrechterhalten, 17 

• Managementreporte und -Bewertungen der IT-Sicherheit erstellen lassen, 18 

• rechtliche Rahmenbedingungen beachten 19 (sog. „Compliance“). 

419 Für die Initiierung und die Umsetzung der sich aus den Sicherheitszielen und 
Sicherheitsrichtlinien ergebenden Prozesse sind organisatorische und personelle 
Festlegungen zu treffen und Betriebsräte rechtzeitig zu beteiligen. 20 Den verschie- 
denen Organisationsebenen und hier tätigen Personen sind konkrete Handlungs- 
anweisungen und Verantwortlichkeiten zur Abwicklung der sie betreffenden Pro- 
zesse zuzuweisen 21 . 

420 Der Einsatz der erforderlichen Betriebsmittel ist auf die Aufgabenerfüllung und 
die Sicherheitsanforderungen abzustimmen und über eine Betriebsmittelverwal- 
tung zu dokumentieren. Diese Dokumentation muss vollständig sein und durch 
entsprechende Prozesse auch jederzeit aktuell gehalten werden. 

421 Notwendig sind weitere Regelungen für Ersatzteilbeschaffung, Reparaturen und 
Wartungsarbeiten. 22 In Wartungs- und Pflegeverträgen ist die Wartung einzelner 
IT-Systeme (oder Gruppen) terminlich und inhaltlich verbindlich zu regeln, eben- 
so wie die zur Erfüllung dieser Verträge erforderlichen Zugänge („Remote“ oder 
vor Ort) und die an die Sicherheitsanforderungen angepassten Reaktionszeiten des 
mit der Wartung beauftragten Personals. Die Aufgabenverteilung und die hierfür 
erforderlichen Funktionen 23 sind so zu strukturieren, dass operative und kontrol- 
lierende Funktionen auf verschiedene Personen verteilt werden, um Interessens- 
konflikte bei den handelnden Personen zu minimieren oder ganz auszuschalten. 

422 Durch Anwendung des Need-to-Know-Prinzips und des Vier-Augen-Prinzips ist 
sicherzustellen, dass Berechtigungen auf den verschiedenen Ebenen (z. B. Zutritt 



15 GS-Handbuch M 2.193. 

16 GS-Handbuch M 2.192. 

17 GS-Handbuch, M 2.199 (A). 

18 GS-Handbuch, M 2.200 (C). 

19 GS-Handbuch M 2.340 (A). 

20 GS-Handbuch, M 2.40. 

21 GS-Handbuch, M 2.225. 

22 gemäß GS-Handbuch, M 2.4. 
gemäß GS-Handbuch, M 2.5. 
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zu Räumen, Zugang zu IT- Systemen) zielgerichtet vergeben werden und auch 
praktikabel sind. 24 Diese Berechtigungen sind zu dokumentieren und durch ver- 
schiedene Methoden zu unterstützen, wie z. B. kontrollierte und nachweisbare 
Ausgabe von Schlüsseln nur an Berechtigte 25 , Authentisierung von Zugriffen, 
Zutrittskontrollsysteme für speziell gesicherte Bereiche und Kontrolle der Aktio- 
nen Betriebsfremder. 26 Werden Regelungen bewusst oder unbewusst verletzt, so 
müssen die hieraus ableitbaren Informations- und Eskalationsprozesse den Mitar- 
beitern bekannt sein, so dass eine zielgerichtete Sanktion auf die Verletzung erfol- 
gen kann. 27 

3. Grundlagen des IT-Sicherheitsmanagements 

Das Grundschutzhandbuch des Bundesamtes für Sicherheit in der Informations- 423 
Verarbeitung (BSI), im vorliegenden Zusammenhang wohl das maßgebliche Do- 
kument, weist der sicheren Verarbeitung von Informationen heutzutage für nahe- 
zu alle Unternehmen und Behörden existenzielle Bedeutung zu. 28 Für den Schutz 
der Informationen reicht es nicht aus, nur technische Sicherheitslösungen einzu- 
setzen, sondern es muss ein geplantes und organisiertes Vorgehen aller Beteiligten 
erreicht und aufrechterhalten werden (IT-Sicherheitsmanagement). 

Das Grundschutzhandbuch zeigt auf, wie ein funktionierendes IT-Sicherheits- 424 
management eingerichtet und im laufenden Betrieb weiterentwickelt werden kann. 

Auf der Grundlage des BSI-Standard 100-1 (Managementsysteme für Informa- 
tionssicherheit) und BSI-Standard 100-2 (Vorgehensweise nach IT- Grundschutz) 
beschreibt es hierfür sinnvolle Schritte eines systematischen IT-Sicherheitsprozes- 
ses und gibt Anleitungen zur Erstellung eines umfassenden IT-Sicherheitskonzep- 
tes. Die Art der Maßnahmen und die Schritte zu ihrer Umsetzung können also 
betriebsindividuell gewählt werden. Grundsätzlich gehören hierzu aber die Kon- 
zeption und der Aufbau geeigneter Organisationsstrukturen, das Einrichten und 
Erhalten von IT-Sicherheitsprozessen und die regelmäßige Revision. 

Das Sicherheitsmanagement muss als ITIL-Anforderung mit dem Management 425 
von Störungsprozessen verzahnt werden. 29 Zu integrieren sind insbesondere häu- 



24 gemäß GS-Handbuch Bl.l und M 2.6. 

25 GS-Handbuch, Bl.l und M 2.14. 

26 GS-Handbuch B 1.1 und M 2.16. 

27 GS-Handbuch, Bl.l und M 2.39. 

28 GS-Handbuch B 10. 

29 Bundesamt für Sicherheit in der Informationstechnik (BSI), ITIL und Informationssi- 
cherheit - Möglichkeiten und Chancen des Zusammenwirkens von IT-Sicherheit und 
IT-Service-Management 2005, www.bsi.bund.de, 16. Zu den ITIL-Anforderungen s. a. 
Rdn. 648. 
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fig bisher isoliert implementierte Systeme zum Erkennen von Angriffen (Intrusion 
Detection), zur Behandlung von Sicherheitsvorfällen und zur Durchführung fo- 
rensischer Analysen (detaillierte Analysen der benutzten Sicherheitslücken, Spu- 
rensicherung und erste Täterverfolgung), um erkannte Störungen zentral zu erfas- 
sen und zu behandeln. 30 Schnittstellen bestehen auch zum Konfigurationsma- 
nagement, das Informationen über alle eingesetzten Konfigurationselemente wie 
Anwendungen, Netzwerke, Geräte, aber auch Störungen, Probleme und Änderun- 
gen erfasst. Hierzu gehören auch Anwendungsprozesse sowie Services und Rol- 
len. 31 Letztere sind mit Personen verbunden, sodass eine Datenbank zum Konfigu- 
rationsmanagement auch eine Vielzahl von Arbeitnehmerdaten enthalten kann. 
Aufgabe des Betriebsrats ist, auf eine Regelung hinzuwirken, nach der möglichst 
wenige solcher Personaldatentypen gesammelt bzw. möglichst viele nur anonymi- 
siert verarbeitet werden. Das gilt insbesondere für die Verknüpfung von Daten 
über Störungsprozesse mit Arbeitnehmerdaten. 

426 Betriebliche IT-Systeme werden nicht im rechtsfreien Raum genutzt, sondern in 
einem mittlerweile recht dichten Geflecht von rechtlichen Regelungen, die vom 
Unternehmen einzuhalten sind („Compliance“). Sie betreffen etwa handeis- und 
steuerrechtliche Vorgaben für die Archivierung von E-Mails, die Grundsätze für 
ordnungsgemäße DV-gestützte Buchführungssysteme (GoBS) 32 oder die Prüfbar- 
keit digitaler Unterlagen (GDPdU), aber auch Best-Practice-Sammlungen wie 
„ITIL“ und Normen wie ISO 20000. Mittlerweise werden für die Erfüllung der 
unterschiedlichen Pflichten am Markt „Compliance“-Lösungen 33 angeboten. 

427 Die Einhaltung der Rechtspflichten wie der getroffenen Sicherheitmaßnahmen 
muss dokumentiert werden. Diese Dokumentation muss für eine ausreichende 
Dauer, etwa für die gesamte Dauer laufender gesetzlicher Aufbewahrungsfristen 
technisch gesichert archiviert werden. Die Geschäftsleitung muss hier klären, für 
welchen Zeitraum Wartungs- bzw. Supportverträge jedenfalls noch laufen bzw. 
verlängert werden können und welche alternativen Speichermedien in Betracht 
kommen, auf die gewechselt werden kann bzw. ob ein solches „Umkopieren“ von 
Datenbeständen überhaupt zulässig ist oder vielmehr immer auch die Kopiervor- 
lage reproduzierbar erhalten bleiben muss. 



30 BSI, ITIL und Informationssicherheit, a.a.O., 17. 

31 BSI, ITIL und Informationssicherheit, a.a.O., 22. 

32 BMF-Schreiben vom 7.11.1995 - IV A 8 - S 0316 - 52/95 - BStBl 1995 I, 738. 

Zu solchen Compliance-Systemen s. Friedmann , Compliance - Programm statt Projekt, 
Computerwoche 14/2005, 36. 



33 
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4. Einrichten und Erhalten des IT-Sicherheitsprozesses 

Ziel des IT-Sicherheitsmanagements muss sein, einen funktionierenden IT- 428 
Sicherheitsprozess einzurichten und laufend funktionsfähig zu erhalten. Dieses 
Ziel kann mit den nachfolgend aufgelisteten Schritten erreicht werden. 34 

Schritt 1: Erstellung einer IT-Sicherheitsleitlinie 

Die IT-Sicherheitsziele sind von den übergeordneten Geschäftszielen, der Marke- 429 
tingstrategie und den allgemeinen Sicherheitsanforderungen des Unternehmens 
her zu bestimmen. Je größer die Abhängigkeit von der eingesetzten IT ist und je 
mehr es auf deren Funktionsfähigkeit ankommt, desto wichtiger ist die Berück- 
sichtigung der IT-Sicherheitsziele auf allen Ebenen der Organisation. 35 

Auf der Grundlage dieser von der Leitungsebene beschlossenen IT-Sicherheits- 430 
zielen ist dann die IT-Sicherheitsleitlinie zu erstellen, in der die zur Erreichung der 
IT-Sicherheitsziele notwendigen internen Organisationsstrukturen, Richtlinien, 
Regeln und Vorgaben definiert werden. Die IT-Sicherheitsleitlinie ist allen davon 
betroffenen Mitarbeitern in geeigneter Form bekannt zu machen. 

Schritt 2: Auswahl und Etablierung einer geeigneten Organisationsstruktur für 
IT-Sicherheit 

Die Geschäftsleitung muss einen geeigneten organisatorischen Rahmen schaffen 431 
und die relevanten Verantwortlichkeiten delegieren. Hierbei muss das IT- 
Sicherheitskonzept unternehmensweit umgesetzt werden, um ein einheitliches 
Sicherheitsniveau zu erreichen. 36 

Je nach Unternehmensgröße ist ein IT-Sicherheitsmanagement-Team einzuset- 432 
zen (welches in größeren Organisationen sämtliche übergreifenden Belange der 
IT-Sicherheit regelt und Pläne, Vorgaben und Richtlinien erarbeitet) oder ein 
IT- Sicherheitsbeauftragter zu benennen (der eine eigene Fachkompetenz für IT- 
Sicherheit aufbaut und für alle IT-Sicherheitsfragen in der Organisation zuständig 
ist). Auch diese erfolgte Regelung ist bekanntzugeben. 37 

IT- Sicherheitsbeauftragte und IT-Sicherheitsmanagement-Team müssen, dem 433 
BSI-Grundschutz-Handbuch zufolge, klar definierte Aufgaben, Verantwortungen 



34 Vorgaben des BSI-Grundschutz-Handbuchs, M 2.191. 

35 GS-EIandbuch M 2.191. 

36 GS-Handbuch M 2.193. 

37 GS-Handbuch M 2.191. 
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und Kompetenzen haben, die von der Leitungsebene festzulegen sind, und sollten 
zur Aufgabenerfüllung bei allen relevanten Verfahren und Entscheidungen betei- 
ligt werden. 38 

434 Der IT-Sicherheitsbeauftragte ist verantwortlich für die Wahrnehmung aller Be- 
lange der IT-Sicherheit innerhalb der Organisation, so etwa für die Koordination 
39 der Erstellung von IT-System-Sicherheitleitlinie(n), des IT-Sicherheitskonzepts, 
des Notfallvorsorgekonzepts und Realisierungsplanes für IT-Sicherheitsmaßnah- 
men und die Initiierung und Überprüfung der Realisierung und das Feststellen 
und Untersuchen auftretender sicherheitsrelevanter Zwischenfälle. Das IT- 
Sicherheitsmanagement-Team hat den IT-Sicherheitsbeauftragten bei der Wahr- 
nehmung seiner Aufgaben zu unterstützen, indem es übergreifende Maßnahmen 
in der Gesamtorganisation koordiniert, Informationen zusammenträgt und Kon- 
trollaufgaben durchführt. 

Schritt 3: Erstellung einer Übersicht über vorhandene IT- Systeme 

435 Zur Steuerung der IT-Sicherheit muss als unabdingbare Voraussetzung eine voll- 
ständige Übersicht über die in einem Unternehmen eingesetzten IT-Systeme sowie 
die auf ihnen betriebenen IT- Anwendungen und die dabei verarbeiteten Daten 
erstellt werden. 

Schritt 4: Festlegen der Vorgehensweise für die Erstellung des IT-Sicherheits- 
konzepts 

436 Die bestehenden Schwachstellen müssen identifiziert sowie geeignete IT-Sicher- 
heitsmaßnahmen ausgewählt und realisiert werden. Standardsicherheits-maßnah- 
men nach IT-Grundschutz sind auch für hochschutzbedürftige IT-Systeme unver- 
zichtbar, aber u.U. um adäquate höherwertige Maßnahmen zu ergänzen. 40 

Schritt 5: Umsetzung der IT-Sicherheitsmaßnahmen 

437 In einem Realisierungsplan ist die Umsetzung der bei der Erstellung des 
IT-Sicherheitskonzepts identifizierten IT-Sicherheitsmaßnahmen zu organisieren 
und festzuhalten. Er dient als Planungsinstrument bei der Koordinierung der 
Maßnahmenumsetzung und als Steuerungsinstrument für die eigentliche Umset- 
zung. Alle zur Aktualisierung oder Implementierung von Maßnahmen notwendi- 
gen Aktionen und Verantwortlichkeiten sollten hierin schriftlich fixiert werden. 41 



38 GS-Handbuch M 2.193. 

39 GS-Handbuch M 2.193. 

40 GS-Handbuch M 2.191. 
GS-Handbuch M 2.191. 
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Schritt 6: IT- Sicherheit im laufenden Betrieb 

Damit alle Mitarbeiter eines Unternehmens die sie jeweils betreffenden Maßnah- 438 
men korrekt umsetzen sowie verbleibende Schwachstellen erkennen und sich aktiv 
an deren Beseitigung beteiligen können, muss eine hinreichende Schulung zu 
Fragen der IT-Sicherheit und eine kontinuierliche Sensibilisierung für Risiken und 
Verbesserungsmöglichkeiten im laufenden Betrieb durchgeführt werden, auch um 
die Akzeptanz der IT-Sicherheitsmaßnahmen durch die Mitarbeiter zu erhöhen. 42 

Schritt 7: Aufrechterhalten des sicheren Betriebs 

Das angestrebte Sicherheitsniveau muss dauerhaft aufrechterhalten und regelmä- 439 
ßig überprüft werden, da ein einmal etabliertes Sicherheitsniveau schnell veralten 
kann, so etwa durch Erkenntnisse aus sicherheitsrelevanten Zwischenfällen, Ver- 
änderungen im technisch-organisatorischen Umfeld sowie Änderungen von Si- 
cherheitsanforderungen bzw. neue Bedrohungen. Diese Anpassungen sind zu 
dokumentieren. 43 Der Nachweis solcher regelmäßiger Überprüfungen kann für die 
bankseitige Beurteilung der Bonität des anwendenden Unternehmens von Bedeu- 
tung sein. 

5. IT-Sicherheitskonzept 

Das IT-Sicherheitskonzept dient zur Umsetzung der IT- Sicherheitsstrategie. In 440 
ihm ist die geplante Vorgehensweise zu beschreiben, mit der die gesetzten Sicher- 
heitsziele erreichbar sind. Das IT-Sicherheitskonzept ist das zentrale Dokument 
im IT- Sicherheitsprozess eines Unternehmens und muss sorgfältig geplant und 
umgesetzt sowie regelmäßig überarbeitet werden. 44 

Basis jeder Risikobewertung muss die Beschreibung der zu schützenden Infor- 441 
mationen und Geschäftsprozesse sein. Zu analysieren ist, welche Gefährdungen 
bzw. Risiken als Folge unzureichender IT-Sicherheit bestehen, ebenso mögliche 
Schäden durch Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit und die 
potentiellen Auswirkungen auf die Geschäftstätigkeit oder die Aufgabenerfüllung 
durch IT-Sicherheitsvorfälle und andere IT-Sicherheitsrisiken. Hieraus lässt sich 
das Risiko für das Unternehmen bzw. die Behörde abschätzen und der Schutzbe- 
darf für Informationen, IT- Anwendungen und IT-Systeme festlegen. 45 Aus der 
Gesamtheit von allgemeinen IT-Sicherheitszielen, dem identifizierten Schutzbe- 



42 GS-Handbuch M 2.191. 

43 GS-Handbuch M 2.191. 

44 GS-Handbuch, M 2.195. 
GS-Handbuch, M 2.195. 
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darf und der Risikobewertung werden schließlich konkrete IT-Sicherheitsmaß- 
nahmen passend zum betrachteten IT- Verbund abgeleitet. 46 

442 Die Dokumentation sollte konkrete Angaben über Verantwortlichkeiten und 
Zuständigkeiten sowie geplante Aktivitäten zur Kontrolle, Revision, Überwachung 
enthalten. Schließlich muss der Sicherheitsprozess kontinuierlich verbessert und 
aktualisiert werden, um sicherzustellen, dass auf neue technische Entwicklungen 
reagiert werden kann und vor allem Schwachstellen und aufgedeckte Sicherheits- 
lücken berücksichtigt werden. Die Änderungen sind zu dokumentieren. 47 

443 Die Verantwortung der Geschäftsleitung umfasst als Ziel der Umsetzung die 
Ausgestaltung der Regelungen des Konzepts, die Beschaffung der Hilfsmittel, 
Gestaltung von technischen oder organisatorischen Abläufen an den Arbeitsplät- 
zen, die Anpassung von Aufgabenbeschreibungen, die Bereitstellung von Anlei- 
tungen und die Information der betroffenen Mitarbeiter. 48 Jeder Mitarbeiter muss 
an der Gewährleistung der IT-Sicherheit mitwirken, also insbesondere durch ver- 
antwortungs- und qualitätsbewusstes Handeln Schäden vermeiden und zum Er- 
folg beitragen. 49 

6. Aufrechterhalten der IT-Sicherheit 

444 Im IT-Sicherheitsprozess muss das angestrebte IT-Sicherheitsniveau dauerhaft 
gewährleistet sein. Soweit ein Anbieter beauftragt ist, muss er die Sicherheit lau- 
fend unterstützen und der Vertrag ist entsprechend auszugestalten. Alle IT- 
Sicherheitsmaßnahmen sind regelmäßig zu überprüfen, 50 wobei der Auftraggeber 
die Vertragserfüllung durch den Anbieter regelmäßig zu kontrollieren hat. Unter- 
schieden wird zwischen der Prüfung, ob bestimmte Maßnahmen geeignet und 
effizient sind, um die gesteckten Sicherheitsziele zu erreichen (Vollständigkeits- 
bzw. Aktualisierungsprüfung), und der Kontrolle, inwieweit Sicherheitsmaß- 
nahmen in den einzelnen Bereichen umgesetzt wurden (IT-Sicherheitsrevision). 
Die im IT- Sicherheitskonzept geplanten IT-Sicherheitsmaßnahmen müssen ge- 
mäß dem Realisierungsplan umgesetzt werden. Der Umsetzungsstatus muss do- 
kumentiert werden. Zieltermine und Ressourceneinsatz müssen überwacht und 
gesteuert werden. 



46 GS-Handbuch, M 2.195. 

47 GS-Handbuch, M 2.195. 

48 GS-Handbuch, M 2.196. 

49 GS-Handbuch, M 2.197. 
GS-Handbuch, M 2.199. 
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Die Überprüfungen sollten zu festgelegten Zeitpunkten durchgeführt werden und 445 
können bei gegebenem Anlass auch zwischenzeitlich erfolgen. Insbesondere Er- 
kenntnisse aus sicherheitsrelevanten Zwischenfällen, Veränderungen im techni- 
schen oder technisch-organisatorischen Umfeld sowie Änderungen von Sicher- 
heitsanforderungen bzw. Bedrohungen erfordern eine Anpassung der bestehenden 
IT-Sicherheitsmaßnahmen. Die in den einzelnen Überprüfungen ermittelten Er- 
gebnisse sollten dokumentiert werden, und es muss festgelegt sein, wie mit den 
Überprüfungsergebnissen zu verfahren ist. Erforderliche Korrekturmaßnahmen 
sind rechtzeitig zu ergreifen. 

Die vorhandenen IT-Sicherheitsmaßnahmen sollten mindestens einmal im Jahr 446 
überprüft werden. Darüber hinaus sind sie immer dann zu prüfen, wenn 51 

• neue IT-Komponenten oder Prozesse implementiert werden, 

• größere Änderungen der Infrastruktur vorgenommen werden (z. B. Umzug), 

• größere organisatorische Änderungen anstehen (z. B. Outsourcing), 

• die Gefährdungslage sich wesentlich ändert, 

• gravierende Schwachstellen oder Schadensfälle bekannt werden. 

7. Betriebliche Regelung der IT-Sicherheit 

Die die Sicherheit der Nutzung betrieblicher IT-Systeme betreffenden Regelungen 447 
sollten in einem Dokument (einer sog. „IT Security Policy“) gesammelt und als 
Betriebsvereinbarung verbindlich gemacht werden. Der Betriebsrat ist zur Über- 
prüfung der Einhaltung von IT Security Policies und Sicherheitsrichtlinien ver- 
pflichtet und über deren Erstellung zu unterrichten und diese sind mit ihm zu 
beraten. Der Betriebsrat muss die Einhaltung bzw. Wirksamkeit der verschiedenen 
in Gesetzen oder Betriebsvereinbarungen enthaltenen Sicherheitsregelungen über- 
prüfen. Dies muss laufend (jedenfalls in regelmäßigen Abständen) geschehen, 52 da 
sich in der Praxis die „Befolgungsrate“ verschlechtern kann. 

IT-bezogene Regelungen dürfen außerdem nicht pauschal und unverändert aus 448 
Regelungsmustern übernommen werden, sondern bedürfen der fallspezifischen 
Anpassung. Voraussetzung hierfür ist eine Risikoanalyse der unterschiedlichen 
konkreten Gegebenheiten (und insbesondere Gefährdungen), aus deren Ergebnis- 



51 GS-Handbuch, M 2.199. 

52 Der Leitfaden IT-Sicherheit des BSI, a.a.O., 16 Nr. 4 stellt klar fest: „IT-Sicherheit ist ein 
dauerhafter Prozess“. 
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sen dann die betriebsspezifischen Regelungen abzuleiten sind 53 und das IT-Sicher- 
heitskonzept konsolidiert werden muss. Schutzziele sind die „drei Grundwerte der 
IT-Sicherheit“, nämlich Vertraulichkeit, Integrität und Verfügbarkeit. 54 

449 Die jeweils relevanten IT-Sicherheitsaspekte müssen bei allen Projekten frühzeitig 
und ausreichend berücksichtigt werden. 55 Das nachträgliche Implementieren von 
Sicherheit in bereits erworbene Systeme kann, wenn es überhaupt technisch mög- 
lich ist, nämlich zu erheblichen Zusatzkosten führen. Konkret bedeutet dies, dass 
die benötigten Sicherheitselemente eines IT-Systems bereits in der Leistungsbe- 
schreibung des Auftrags festgelegt und damit bei dessen Ausschreibung den mög- 
lichen Auftragnehmern mitgeteilt werden müssen. Der Betriebsrat ist berechtigt, 
rechtzeitig vor Auftragserteilung die Ausschreibungsunterlagen einzusehen (§ 80 
Abs. 2S. 2 BetrVG), um prüfen zu können, ob die erforderlichen Sicherheitsmerk- 
male vorgesehen sind (soweit Arbeitnehmerbelange betroffen sein können). Früh- 
zeitige Kooperation ist hier dringend zu empfehlen, da erfahrungsgemäß ein an- 
dernfalls „drohendes“ Einigungsstellenverfahren (§§ 76 ff BetrVG) ein IT-Projekt 
um Monate oder gar Jahre verzögern kann. 

450 Die IT-Sicherheitsziele müssen bereits festgelegt sein, bevor zu ihrer Erreichung 
angemessene Maßnahmen definiert werden können. 56 In einer Schutzbedarfsfest- 
stellung sollten insbesondere die voraussichtlichen Risiken und die zu schützen- 
den Werte (insbesondere Vertraulichkeit, Integrität und Verfügbarkeit) und mög- 
liche Schadensauswirkungen auf diese geprüft werden, wobei diese Prüfung 
regelmäßig zu wiederholen ist, 57 und zwar auch bezüglich Arbeitsabläufen und 
Sicherheitsrichtlinien, da sich die Schutzziele ändern können. 

451 Technische und organisatorische Absicherung der betrieblichen IT ist schließlich 
kein einmal durchzuführendes Projekt, sondern muss während des gesamten 
produktiven IT-Einsatzes durchgeführt und regelmäßig auf Wirksamkeit über- 
prüft werden. Andernfalls kann sich die Sicherheit gerade auch von Arbeitneh- 
merdaten durch die häufig notwendigen Änderungen stetig verschlechtern. 58 



53 Ausführliche Hinweise zur Durchführung dieser Risikoanalyse finden sich im Doku- 
ment BSI (Bundesamt für Sicherheit in der Informationstechnik) -Standard 100-3 - Ri- 
sikoanalyse auf der Basis von IT-Grundschutz, Version 2.0, www.bsi.bund.de. 

54 BSI, Standard 100-3 - Risikoanalyse auf der Basis von IT-Grundschutz, 9. 

55 BSI, Leitfaden IT-Sicherheit - IT-Grundschutz kompakt, 16 Nr. 1. 

56 Leitfaden IT-Sicherheit, a.a.O., 16 Nr. 3. 

57 Leitfaden IT-Sicherheit, a.a.O., 16 Nr. 9. 

58 Leitfaden IT-Sicherheit, a.a.O., 12. 
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Nachfolgend werden wichtige typische Regelungsinhalte einer IT Security Policy 452 
zusammengefasst. 

• Umgang mit schützenswerten Informationen (Festlegung von Informationsei- 
gentümern, Pflicht zur Klassifizierung von Informationen), 

• relevante Gesetze und V orgaben, 

• Kurzbeschreibung wichtiger Rollen (IT-Sicherheitsbeauftragter, Administrator, 
IT-Benutzer), 

• Personalmaßnahmen (Schulung, Pflicht zur Einrichtung von Vertretungsre- 
geln), 

• Anforderungen an die Verwaltung von IT (Beschaffung, Einsatz, Wartung, 
Revision und Entsorgung), 

• grundlegende Sicherheitsmaßnahmen (Zutritt zu Räumen und Zugang zu IT- 
Systemen, Verschlüsselung, Virenschutz, Datensicherung, Notfallvorsorge), 

• Regelungen für spezifische IT-Dienste (Datenübertragung, Internet-Nutzung). 

8. Sicherheitsrichtlinien 

Sicherheitsvorgaben müssen in einer Sicherheitsrichtlinie für die Mitarbeiter (in 453 
der Form einer Betriebsvereinbarung) verbindlich gemacht werden. 59 Die Einhal- 
tung von bestehenden Sicherheitsrichtlinien und -vorgaben muss kontrolliert 
werden. Verstöße müssen zu Sanktionen führen. 60 Teil einer solchen Richtlinien- 
einhaltung kann etwa das durchgängige Verschlüsseln von E-Mails sein. 61 Zum 
Richtlinieninhalt können aus Raumgründen nur einige besonders wichtige Aspek- 
te herausgegriffen werden: 

Die Vergabe von Benutzerrechten sollte restriktiv gehandhabt werden, insbeson- 454 
dere jeder Benutzer (und auch jeder Administrator) nur auf jene Datenbestände 
zugreifen und jene Programme ausführen dürfen, die er für seine tägliche Arbeit 
auch wirklich benötigt (sog. „Need-to-know-Prinzip“). 62 Freilich erfordert dies 
eine sorgfältige Ausdifferenzierung von Zugriffsrechten. 

Datenzugriffsrechte und Systemprivilegien sollten auf das erforderliche Min- 455 
destmaß beschränkt werden (ebenso Administratorenrechte). 63 Hierzu lassen sich 
Berechtigungsprofile entwickeln. In regelmäßigen Abständen sollte geprüft wer- 



59 Bundesamt für Sicherheit in der Informationstechnik (BSI), Leitfaden IT-Sicherheit - 
IT-Grundschutz kompakt, 12, 18 Nr. 12. 

60 Leitfaden IT-Sicherheit, a.a.O., 12/13. 

61 Leitfaden IT-Sicherheit, a.a.O., 13. 

62 Leitfaden IT-Sicherheit, a.a.O., 13. 

63 Leitfaden IT-Sicherheit, a.a.O., 19 Nr. 15 und 17. 
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den, ob die für eine Person verfügbaren Zugriffsrechte noch deren Tätigkeitsprofil 
entsprechen oder ob Einschränkungen zweckmäßig wären. 64 Die jeweilige Berech- 
tigung muss durch einen geeigneten Prozess eingeräumt oder (etwa bei Ausschei- 
den) widerrufen werden können. 65 

456 Sensitive Systeme müssen gegen den Zugriff aus offenen Netzen sicher abgeschot- 
tet werden. Im Einzelfall muss geprüft werden, ob eine Öffnung des Systems zum 
Internet wirklich unabdingbar ist, da auch die Existenz einer Firewall noch keine 
Garantie für eine Zugriffsabsicherung darstellt. 66 

457 Sinngemäß Gleiches gilt für die Abschottung von Funknetzen (WLANs), auf die 
beliebige Dritte zugreifen können, wenn z.B. eine Verschlüsselung unzureichend 
ist (WEP 67 ) oder überhaupt nicht existiert. 68 Sicherzustellen ist, dass nicht beliebi- 
ge Fremde sich auf der Straße vor dem Unternehmen mit portablen Rechnern in 
das Unternehmens-WLAN einloggen und nicht ausreichend gegen solche Zugriffe 
geschützte Daten (z.B. medizinische Daten des Betriebsarztes) herunterladen. 

458 Auch die Verpflichtung zu regelmäßiger Datensicherung ist zu regeln. Das gilt 
auch für (in der Praxis nur selten gesicherte) Datenbestände auf Notebooks. 69 

459 Verfügbare Sicherheits-Updates müssen auch tatsächlich und umgehend einge- 
spielt werden. 70 Bei manchen Programmen führt freilich die Vielzahl der anfallen- 
den Sicherheits-Patches zu nicht unerheblichem Aufwand an Arbeitszeit (insbe- 



64 Leitfaden IT -Sicherheit, a.a.O., 20. 

65 Leitfaden IT -Sicherheit, a.a.O., 20. 

66 Leitfaden IT -Sicherheit, a.a.O., 13. 

67 „WEP“ steht für „Wired Equivalent Privacy“ und ist ein Verfahren zur Verschlüsselung 
von per Funk übertragenen Datenpaketen, das statische Codes verwendet (mit den 
Schlüssellängen WEP64 und WEP128). Es gilt seit Februar 2001 als unsicher (Compu- 
terwoche 15/2004, 14). Im mehr Sicherheit aufweisenden „WPA“ (Wifi Protected Ac- 
cess) -Verfahren werden dynamische Schlüssel verwendet, die länger (und damit siche- 
rer) sind und häufiger in kurzen Abständen gewechselt werden. Der Betriebsrat sollte 
sicherstellen, dass ein aktueller Sicherheitsstandard wie WPA2 (basierend auf IEEE 
802.1 li bzw. WAP2-Enterprise) verwendet wird (ausführlicher Hruby, WLANs richtig 
absichern, Computerwoche 23/2006, 34). 

68 Der Leitfaden IT- Sicherheit, a.a.O., 12 des BSI stellt hierzu deutlich fest: „Begeisterung 
für eine neue Technik und die Möglichkeit, auf lästige Verkabelung verzichten zu kön- 
nen, lassen Sicherheitsaspekte vergessen. Unzählige Firmen „veröffentlichen“ somit un- 
freiwillig ihre vertraulichen Daten und bieten teilweise allen Interessierten kostenlose 
Internetzugänge an“ - also auf Unternehmenskosten und zulasten auch der Mitarbeiter, 
deren Daten ebenfalls in WLANs ungesichert bleiben und für unberechtigte Dritte zu- 
greifbar werden, etwa Krankeitsdaten aus der Personalakte. 

69 Leitfaden IT- Sicherheit, a.a.O., 14. 

70 Leitfaden IT- Sicherheit, a.a.O., 14. 
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sondere bei erforderlicher Installation auf Hunderten von PCs oder Notebooks 
mit unterschiedlichen Betriebssystem- Versionen). Auf Websites von Anbietern 
von Sicherheitssoftware sollte regelmäßig nachgesehen werden, ob neue Updates 
verfügbar sind. Einige Anbieter haben automatisierte E-Mail-Dienste zur Benach- 
richtigung, die abonniert werden sollten. Achtung: Während des Download des 
Updates kann das System vor Angriffen Dritter ungeschützt sein. Bei erhöhtem 
Schutzbedarf sollte der Download auf einen getrennten, d.h. nichtvernetzten 
Rechner mit separatem Internet-Anschluss erfolgen. 

Die Verwaltung der Versionen von Web-Browsern sollte einheitlich geregelt sein. 460 
Das gilt nicht nur für das Updating als solches, sondern auch für im Netz herun- 
terladbare kleine Zusatzprogramme, z.B. Multimedia-Plugins . 71 Diese können zum 
Einfallstor für Angriffe Dritter werden. Die riskanten Skriptsprachen sollten re- 
gelmäßig deaktiviert werden, da sich mit diesen serverseits unkontrollierbare Er- 
weiterungen am Arbeitsplatz erstellen lassen . 72 Hierdurch wird die Kontrolle 
durch Systemadministratoren und damit letztlich die Sicherheit der Arbeitneh- 
merdaten beeinträchtigt. 

Passwörter müssen sorgfältig ausgewählt und sicher aufbewahrt werden . 73 Leicht 461 
erratbare Buchstabenkombinationen haben wenig Wert . 74 Arbeitsplatzrechner 
sollten bei Verlassen mit Bildschirmschoner und Kennwort gesichert sein . 75 Beides 
sollte in den Sicherheitsrichtlinien geregelt sein. Standardmäßige Voreinstellungen 
(z.B. automatisch vergebene Passwörter) eines IT-Systems beim Rollout sollten 
vor Beginn der produktiven Nutzung geändert werden . 76 

Verschlüsselung sollte soweit wie möglich eingesetzt werden. Datenbestände auf 462 
Notebooks sollten komplett verschlüsselt (und auf externem Datenträger gesi- 
chert) werden, da Diebstahlsgefahr besteht . 77 

Virenschutzprogramme müssen flächendeckend (also z.B. an allen Arbeitsplätzen 463 
mit Internet-Zugang) eingesetzt werden . 78 In Sicherheitsrichtlinien muss eine 
Verpflichtung geregelt sein, Sicherheits-Updates auch tatsächlich einzuspielen. 



71 Leitfaden IT-Sicherheit, a.a.O., 23. 

72 Leitfaden IT-Sicherheit, a.a.O., 23. 

73 BSI, Leitfaden IT-Sicherheit, a.a.O., 14. 

74 Leitfaden IT Sicherheit - IT Grundschutz kompakt, verfügbar unter www.bsi.bund.de, 1 4. 

75 Leitfaden IT-Sicherheit, a.a.O., 28. 

76 Leitfaden IT-Sicherheit, a.a.O., 21 Nr.19. 

77 Leitfaden IT-Sicherheit, a.a.O., 29. 

78 Leitfaden IT-Sicherheit, a.a.O., 19. 
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9. IT-Sicherheitsbeauftragter und IT-Sicherheitsmanagement 

464 Soweit Unternehmen für die IT-Sicherheit einen Sicherheitbeauftragten bestellen, 
ist dieser der Geschäftsleitung unterstellt und dieser verantwortlich bzw. bei Beauf- 
tragung eines Externen aus Vertrag leistungsverpflichtet. Aufgabe des IT-Sicher- 
heitsbeauftragten ist es, Meldungen über Sicherheitsvorfälle entgegenzunehmen, 
die Untersuchung und Bewertung des Vorfalls durchzuführen. Er hat notwendige 
Maßnahmen auszuwählen und deren Umsetzung zu veranlassen, soweit dies nicht 
seinen Kompetenzbereich überschreitet. Bei Bedarf ruft er ein Sicherheitsvorfall- 
Team zusammen bzw. unterrichtet zur Eskalation die Leitungsebene. 79 

465 Jeder IT-Benutzer sollte über die Sicherheitsleitlinie des Hauses verpflichtet wer- 
den, sicherheitsrelevante Unregelmäßigkeiten zu melden. Darüber hinaus sollten 
alle Benutzer schriftliche Handlungsanweisungen ausgehändigt bekommen, wie 
sie sich zu verhalten haben und an wen welche Vorfälle zu melden sind. 80 

466 Der IT- Administrator (auch System operator genannt) erhält in diesem Zusam- 
menhang die Aufgabe, Meldungen über sicherheitsrelevante Unregelmäßigkeiten, 
die mit den von ihm betreuten IT-Systemen verbunden sind, entgegenzunehmen. 
Anschließend hat er zu entscheiden, ob er selbst diese Unregelmäßigkeit behebt 
oder ob er die nächsthöhere Eskalationsebene zu unterrichten hat. Ein Administ- 
rator muss (fachlich, aber auch entscheidungskompetenzmäßig) entscheiden kön- 
nen, ob ein Sicherheitsproblem vorliegt, ob er dieses eigenverantwortlich beheben 
kann, ob er sofort andere Personen hinzuzieht (entsprechend dem Eskalations- 
plan) und wen er informiert. 81 

467 Der Betriebsrat wird durch die Bestellung eines betrieblichen IT-Sicherheitsbeauf- 
tragten nicht von seiner Prüf- und Überwachungspflicht entlastet. Umgekehrt 
unterliegt der Betriebsrat nicht den Weisungen des Sicherheitsbeauftragten (da 
selbst der Arbeitgeber eine solche Weisungsbefugnis nicht hat). Der IT-Sicher- 
heitsbeauftragte darf aber prüfen, ob ein vom Betriebsrat benutztes IT-System die 
Anforderungen der betrieblichen Sicherheitspolitik erfüllt; das gilt insbesondere, 
wenn der Betriebsrat Internet-Zugänge oder E-Mail-Systeme des Betriebs für seine 
Zwecke nutzt. Der Beauftragte darf hier natürlich nicht angesurfte Websites oder 
Inhalte von E-Mails überprüfen, wohl aber, ob gesicherte Zugänge benutzt wer- 
den, ob in den für den Betriebsrat eingehenden E-Mails sicherheitsgefährdende 
Anhänge enthalten und das IT-System des Betriebsrats angriffsgeschützt ist. Der 
Rechner des Betriebsrats darf schließlich nicht zum Einfallstor für Angriffe auf 



79 GS-Handbuch, M 6.58. 

80 GS-Handbuch, M 6.59. 

81 GS-Handbuch, M 6.59. 
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IT-Systeme des Unternehmens werden. Will der Betriebsrat hier solche Kontrollen 
vermeiden, steht es ihm frei, einen separaten, nicht mit Unternehmensnetzen 
verbundenen Rechner zu verwenden und einen Provider mit der Online- 
Anbindung dieses Rechners zu beauftragen. Nachteil dieser Lösung ist aber, dass 
der Betriebsrat von einem solchen „Insel“-Rechner aus nur schwer mit den Ar- 
beitnehmern im Unternehmensnetz elektronisch kommunizieren kann. 

Bei Einstellung des Sicherheitsbeauftragten hat der Betriebsrat aus den §§ 99 ff 468 
BetrVG ein Mitwirkungsrecht. Bei der Entscheidung, ob ein Arbeitnehmer oder 
ein externer Auftragnehmer mit der Aufgabe betraut wird, hat der Betriebsrat ein 
Mitwirkungsrecht. 82 Die Erstellung von durch die Arbeitnehmer als IT-Benutzer 
zu befolgenden Sicherheitsrichtlinien wird oft eine Regelung der Betriebsordnung 
und des Verhaltens der Arbeitnehmer darstellen und deshalb nach § 87 Abs. 1 
Nr. 1 BetrVG mitbestimmungspflichtig sein. Dies gilt umso mehr, wenn das Ar- 
beitnehmerverhalten durch eine IT-Revision regelmäßig kontrolliert wird und 
dies zu personenbezogenen Aufzeichnungen führt, erst recht aber bei automati- 
sierter Kontrolle (§ 87 Abs. 1 Nr. 6 BetrVG). Der Betriebsrat kann ein Mitwir- 
kungsrecht bei der Ausschreibung der Stelle des IT- Administrators haben (§ 93 
BetrVG). 

10. Dokumentation des IT-Sicherheitsprozesses 

Das angemessene Sicherheitsniveau lässt sich nur dann erreichen und aufrechter- 469 
halten, wenn der IT-Sicherheitsprozess verständlich, angemessen, aktuell und 
konsistent dokumentiert wird. 83 Zu dokumentieren sind der Ablauf des IT-Sicher- 
heitsprozesses sowie wichtige Entscheidungen und die Arbeitsergebnisse in den 
einzelnen Phasen, ebenso Arbeitsabläufe, organisatorische Vorgaben und techni- 
sche IT-Sicherheitsmaßnahmen. Zur Bearbeitung von Sicherheitsvorfällen sind 
außerdem technische Unterlagen, wie Protokolle oder für den Vorfall besonders 
relevante System-Meldungen, zu speichern und zu archivieren. 

Allgemein müssen IT-Sicherheitsmaßnahmen für die IT-Benutzer verständlich 470 
dokumentiert werden, den Benutzern also die geltenden Sicherheitsrichtlinien, 
übersichtliche Merkblätter für die sichere Nutzung von IT-Systemen und Anwen- 
dungen sowie zum Verhalten bei Sicherheitsvorfällen, Handbücher und Anleitun- 
gen für die eingesetzten IT-Systeme und Anwendungen zur Verfügung stehen. 



82 Schaub/l/. Koch , Arbeitsrechts-Handbuch, § 241, Rdn. 8 a mit Rechtsprechungsnach- 
weisen zur vergleichbaren Bestellung von Sicherheitsingenieuren nach § 9 Abs. 3 ASiG. 

83 GS-Handbuch, M 2.201. 
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11. Notfallvorsorge-Konzept 

471 Ein Notfallvorsorge-Konzept muss Maßnahmen umfassen, die auf die Wiederher- 
stellung der Betriebsfähigkeit nach (technisch bedingtem bzw. durch fahrlässige 
oder vorsätzliche Handlungen herbeigeführtem) Ausfall eines IT-Systems ausge- 
richtet sind. 84 Für alle kritischen IT-Systeme muss ein Notfallplan vorliegen. 85 Das 
Konzept muss für jeden Einzelfall angepasst entwickelt werden. Hierbei sind die 
entstehenden Kosten dem potentiellen Schaden (Kosten aufgrund mangelnder 
Verfügbarkeit im Notfall) gegenüberzustellen und zu bewerten. Geeignete Maß- 
nahmen sind eine strategische Planung über die Einbeziehung der relevanten 
Geschäftsprozesse bis hin zu konkreten Maßnahmen für die IT-Systeme, die die- 
sen Prozessen zugeordnet sind. 

472 Im Notfallhandbuch können, soweit erforderlich, die Bedingungen und Prozedu- 
ren eines temporären oder permanenten Ausweichbetriebs beschrieben werden. 86 
In Form detaillierter Übersichten sind die verantwortlichen und handelnden Per- 
sonen 87 („Notfall-Organigramm“), die zu treffenden Entscheidungen, die Sofort- 
maßnahmen bei Feststellung eines Notfalls 88 und die Handlungsanweisungen für 
spezielle Ereignisse festzuschreiben. Es beschreibt die präventiven Maßnahmen 89 
sowie die Maßnahmen zur Schadenstabilisierung und zur Wiederherstellung der 
Datenintegrität. 

12. Datensicherungskonzept 

473 Durch regelmäßige Datensicherung ist sicherzustellen, dass mittels eines redun- 
danten Datenbestandes der IT-Betrieb kurzfristig wiederaufgenommen werden 
kann, wenn Teile des operativen Datenbestandes verloren gehen. 90 Zu berücksich- 
tigen sind Faktoren wie das IT-System, das Datenvolumen, die Änderungsfre- 
quenz der Daten und die Verfügbarkeitsanforderungen. Im Datensicherungskon- 
zept ist eine Lösung festzulegen, die diese Faktoren berücksichtigt und gleichzeitig 
unter Kostengesichtspunkten wirtschaftlich vertretbar ist. 91 Erforderliche Maß- 
nahmen sind etwa das Entwickeln eines unternehmensspezifischen Datensiche- 
rungskonzepts 92 , die Verpflichtung der Mitarbeiter zur Datensicherung 93 , die 



84 GS-Handbuch, B 1.3. 

85 Seibold, IT-Risikomanagement, 15. 

86 GS-Handbuch M 6.6. 

87 GS-Handbuch, B 1.3 und M 6.7. 

88 GS-Handbuch M 6.8 Alarmierungsplan. 

89 GS-Handbuch, M 6.13 Erstellung eines Datensicherungsplans. 

90 GS-Handbuch, B.1.4. 

91 GS-Handbuch, M 6.33. 

GS-Handbuch, M 6.33 - M 6.36. 
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Sicherungskopie der eingesetzten Software 94 und die Dokumentation der Datensi- 
cherung 95 . 

Hierzu kann Datensicherung in einem wöchentlichen Rhythmus im Drei- 474 
Generationen-Prinzip gehören 96 und sämtliche Anwendungsdaten sowie die Kon- 
figurationsdaten der eingesetzten Software auf auslagerbare oder ausgelagerte 
Datenträger (Disketten, Wechselplatten, Streamertapes, Server) umfassen. 

13. Computerviren-Schutzkonzept 

Ein Computerviren-Schutzkonzept soll durch geeignete Maßnahmen zum Schutz 475 
vor Schadprogrammen gewährleisten, dass das Auftreten von Computerviren ver- 
hindert oder so früh wie möglich erkannt wird. Zusätzlich sind Maßnahmen zu 
benennen, die Schäden minimieren helfen, wenn ein Schadprogramm nicht recht- 
zeitig entdeckt werden konnte. 97 Da praktisch täglich neue Computerviren auftre- 
ten, müssen an offene Netze angeschlossene Systeme permanent auf Computerviren 
kontrolliert werden. Einzusetzen sind Virensuchprogramme. Das Schutzkonzept ist 
Teil der vom Arbeitgeber herzustellenden Datensicherheit (§ 9 BDSG). 

14. Kryptokonzept 

In einer heterogenen Umgebung können sowohl die lokal gespeicherten Daten als 476 
auch die zu übertragenden Daten wirkungsvoll durch kryptographische Verfahren 
und Techniken geschützt werden. 98 

Das zu entwickelnde Kryptokonzept für den Einsatz von Kryptoverfahren muss 477 
auf das IT-System, das Datenvolumen, das angestrebte Sicherheitsniveau und die 
Verfügbarkeitsanforderungen zugeschnitten sein und alle Einflussgrößen und 
Entscheidungskriterien für die Wahl eines konkreten kryptographischen Verfah- 
rens und der entsprechenden Produkte berücksichtigen, soweit dies unter Kosten- 
gesichtspunkten wirtschaftlich vertretbar ist 99 . Kryptographische Verfahren wer- 
den eingesetzt zur Gewährleistung von Vertraulichkeit, Integrität, Authentizität 
und Nichtabstreitbarkeit auch der verarbeiteten Arbeitnehmerdaten. 



93 GS-Handbuch, M 2.41 (A). 

94 GS-Handbuch, M 6.21 (C). 

95 GS-Handbuch, M 6.37 (A). 

96 Es werden drei verschiedene Datensicherungen erzeugt, bevor die erste überschrieben 
wird. 

97 GS-Handbuch B 1.6. 

98 GS-Handbuch B 1.7. 

99 GS-Handbuch M 2.165. 
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15. IT-Sicherheitssensibilisierung und -Schulung 

478 IT-Sicherheitsmaßnahmen können nur wirken, wenn alle Mitarbeiter davon über- 
zeugt sind, dass IT- Sicherheit einen wesentlichen Teil des Erfolges der jeweiligen 
Organisation ausmacht. Der Arbeitgeber muss hierzu kommunizieren, warum 
bestimmte IT-Sicherheitsmaßnahmen notwendig und sinnvoll sind, und allen 
Mitarbeitern bekannt machen, was von ihnen im Hinblick auf IT-Sicherheit er- 
wartet wird und wie sie in sicherheitskritischen Situationen reagieren sollten. In 
vielen Bereichen wird eine langfristige Verhaltensänderung der Mitarbeiter erfor- 
derlich sein, die sich nur in einem langen und kontinuierlichen Prozess erreichen 
lässt. Einmalige Schulungen oder Sensibilisierungsveranstaltungen reichen hier 
nicht aus. 100 Es ist sicherzustellen, dass alle Mitarbeiter die Abläufe kennen und 
wissen, an wen sie sich wenden müssen, falls Sicherheitsfragen auftreten oder 
Sicherheitsprobleme gelöst werden müssen. 101 

479 Um eine umfassende Sensibilisierung für IT-Sicherheitsfragen in einer Institution 
zu erreichen, sollte ein Programm aufgebaut werden, das unter anderem Schulun- 
gen, Trainingsprogramme, Sicherheitskampagnen und andere Aktivitäten bein- 
halten kann. Die Unterstützung durch die Geschäftsleitung muss während des 
gesamten IT-Sicherheitsprozesses erfolgen. 102 Das Schulungs- und Sensibilisie- 
rungsprogramm muss hierzu strategisch vorbereitet und geplant werden. 103 Weiter 
sind als Basis jedes Schulungsprogramms die Sicherheitsleitlinie und die Sicher- 
heitsrichtlinien zu erstellen. 104 Die IT -bezogenen Schulungen sind in ihrer Durch- 
führung mitbestimmungsbedürftige betriebliche Bildungsmaßnahmen (§ 98 
BetrVG). 

16. Managementbewertung der IT-Sicherheit 

480 Zur Steuerung und zum Aufrechterhalten des IT-Sicherheitsprozesses muss min- 
destens einmal im Jahr eine Managementbewertung der IT-Sicherheit durchge- 
führt werden, in der alle erforderlichen Änderungen am Sicherheitsprozess aufge- 
zeigt und festgelegt werden müssen, z.B. in den Sicherheitszielen oder der 
Sicherheitsleitlinie. Alle Ergebnisse der Managementbewertung müssen doku- 
mentiert und Aufzeichnungen gepflegt werden. 105 Die hierbei zu verwendenden 
Managementreporte können auch auf Arbeitnehmer und deren Leistung oder 



100 GS-Handbuch, B 1.13. 

101 GS-Handbuch, B 1.13. 

102 GS-Handbuch, B 1.13. 

103 GS-Handbuch, M 2.312. 

104 GS-Handbuch, B 2.192. 

105 GS-Handbuch, M 2.200. 
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Verhalten oder auf den Erfolg von betrieblichen Bildungsmaßnahmen bezogene 
Aussagen enthalten und etwa Aufschluss geben, ob und wie die Entscheidungen 
der letzten Managementbewertung umgesetzt wurden und ob die Aktivitäten im 
Rahmen der IT-Sicherheit Erfolg hatten. Hierauf können sich personelle Einzel- 
maßnahmen wie Versetzungen oder Kündigungen stützen. 

17. Protokollierung am Server 

Die am Netzserver mögliche Protokollierung ist in einem sinnvollen Umfang zu 481 
aktivieren. In regelmäßigen Abständen muss der Netzadministrator die Pro- 
tokolldateien des Netzservers überprüfen. Es sollten alle sicherheitsrelevanten 
Ereignisse protokolliert werden, so etwa falsche Passworteingaben für eine Benut- 
zerkennung oder die Sperrung der Benutzerkennung bei Erreichen der Fehlver- 
suchsgrenze, Versuche von unberechtigten Zugriffen, Stromausfall, Daten zur 
Netzauslastung und -Überlastung. Der Umfang zusätzlicher Protokollierung hängt 
u. a. vom Schutzbedarf der jeweiligen IT-Systeme ab. Je höher deren Schutzbedarf 
ist, desto mehr sollte protokolliert werden. Da die Protokolldateien mit der Zeit 
sehr umfangreich werden können, sollten die Auswertungsintervalle so kurz ge- 
wählt werden, dass eine sinnvolle Auswertung möglich ist. Um eine sinnvolle Aus- 
wertung zu ermöglichen, sollte jeder Protokoll-Eintrag Benutzerkennung (!) bzw. 
Prozessnummer, Kennzeichnung des Endgeräts, Datum und Uhrzeit enthalten. 106 

1 8. Regelmäßiger Sicherheitscheck des Netzes 

Der Netzadministrator sollte regelmäßig, mindestens monatlich, einen Sicher- 482 
heitscheck des Netzes durchführen (dürfen). Für praktisch alle Betriebssysteme 
sind Programme verfügbar oder bereits im Lieferumfang des Betriebssystems oder 
der Betriebssystem-Distribution enthalten, die entsprechende Funktionen zur 
Verfügung stellen. Bei einem solchen Sicherheitscheck sollten beispielsweise fol- 
gende Punkte überprüft werden: 107 

• Gibt es Benutzer (Arbeitnehmer, Dritte) ohne Passwort? 

• Gibt es Benutzer, die längere Zeit das Netz nicht mehr benutzt haben? 

• Gibt es Benutzer, deren Passwort nicht die erforderlichen Bedingungen einhält? 

• Welche Benutzer besitzen die gleichen Rechte wie der Administrator? 

• Sind Systemprogramme und Systemkonfiguration unverändert und konsistent? 



106 GS-Handbuch, M. 5.45. 

107 GS-Handbuch, M. 5.8. 
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• Entsprechen die Berechtigungen von 

- Systemprogrammen und Systemkonfiguration, 

- Anwendungsprogrammen und -daten sowie 

- Benutzerverzeichnissen und -daten 
den Vorgaben der Sicherheitsrichtlinie? 

• Welche Netzdienste laufen auf den einzelnen Systemen? Sind sie den Vorgaben 
der Sicherheitsrichtlinie entsprechend konfiguriert? 

483 Standardmäßig sollten alle Benutzer (und auch die Administratoren) in einem 
lokalen Netz mit einem Benutzer-Passwort ausgestattet werden. 108 Bei der Durch- 
führung des Sicherheitschecks sollte der Netzadministrator seine Schritte so do- 
kumentieren, dass sie (beispielsweise bei einem Verdacht auf ein kompromittiertes 
System) nachvollzogen werden können. Die Ergebnisse des Sicherheitschecks 
müssen dokumentiert werden, Abweichungen vom „Sollzustand” muss nachge- 
gangen werden. 109 



108 GS-Handbuch, M. 5.6. 

109 GS-Handbuch, M. 5.8. 




E Leistungsstörungen im Projekt 



In jedem IT-Projekt können Leistungsstörungen auftreten. Die wichtigsten Fall- 484 
gruppen sind Verzug und Schlechtleistung. Auch eine optimale Vertragsgestaltung 
kann Risiken von Pflichtverletzungen nicht vollständig ausschließen, wohl aber 
wesentlich reduzieren. Hierzu ist zunächst zu prüfen, welche Rechte der Auftrag- 
geber bei Auftreten einer Leistungsstörung aus Gesetz hat, und im nächsten 
Schritt, welche vertraglichen Vereinbarungen ergänzend getroffen werden sollten. 



Das Augenmerk muss hierauf gerichtet sein, einzelne Leistungsstörungen im 485 
Projekt in ihren Auswirkungen möglichst auf Teilbereiche des Projekts zu be- 
schränken, um den Erfolg des gesamten Projekts nicht zu gefährden. Das gilt 
nicht nur für Leistungsstörungen wie Verzug mit Teilleistungen oder einzelne 
Mängel, sondern auch die Auswirkungen der Ausübung der Rechte des Auftrag- 
gebers. Diese Ausübung sollte, soweit machbar, möglichst projekterhaltend wir- 
ken. Den Vorzug verdient also etwa die Nacherfüllung (insbesondere Mängelbe- 
seitigung) auch bei mehrfacher Wiederholung gegenüber dem Rücktritt oder die 
Vergütungsminderung gegenüber Schadensersatz statt der Leistung. 



Verzug und Leistungsmängel stellen im modernisierten Schuldrecht Pflichtverlet- 430 
zungen dar, die zudem zu Schadensersatzansprüchen des Auftraggebers führen 
können, wenn der Anbieter die Leistungsstörung zu vertreten hat. (Der Begriff der 
„Pflichtverletzung“ setzt als solcher seit der Schuldrechtsmodernisierung 2002 
kein Vertretenmüssen voraus.) 

1 . Rechte aus Verzug des Auftragnehmers mit der Projektleistung 

Gerät der Auftragnehmer mit der Erbringung von Projektleistungen in Verzug, 487 
stellt dies eine Pflichtverletzung dar (§ 280 Abs. 1 BGB). Der Auftraggeber kann 

• die Zahlung einer vereinbarten Vergütung verweigern, wenn er nicht vorleis- 
tungspflichtig ist (§ 320 Abs. 1 S. 1 BGB), oder 

• vom Vertrag zurücktreten (§ 323 Abs. 1 BGB) und/oder Ersatz des Verzöge- 
rungsschadens verlangen (§ 280 Abs. 1 BGB) oder 





164 



E. Leistungsstörungen im Projekt 



• nach Ablauf einer gesetzten Frist Schadensersatz statt der Leistung. Der Auf- 
tragnehmer ist nicht schadensersatzpflichtig, wenn er die Pflichtverletzung 
nicht zu vertreten hat (§ 280 Abs. 1 S. 2 BGB), wofür er allerdings darlegungs- 
und beweispflichtig ist. Freilich scheidet Verzug ohnehin aus, wenn kein Ver- 
tretenmüssen besteht (§ 286 Abs. 4 BGB). 

488 Vertretenmüssen entfällt bzw. entsteht nicht, wenn etwa der Auftraggeber nicht in 
der erforderlichen Weise mitwirkt. Vertretenmüssen ist aber z.B. zu bejahen, wenn 
der Auftragnehmer nicht rechtzeitig ausreichend fachkompetente Mitarbeiter ein- 
setzt, weil sie noch in einem anderen sich verzögernden Projekt tätig sein müssen. Er 
muss entsprechende „Puffer“ der Leistungsbereitschaft Vorhalten, um solche Verzö- 
gerungen aufzufangen. 

Checkliste zum Anbieterverzug 

489 Um allgemein Rechte aus Verzug (des Anbieters mit der Leistung oder des Kun- 
den mit der Zahlung) geltend machen zu können, muss 

• ein nicht einredebehafteter Anspruch des Gläubigers (Kunden) bestehen, 

• Fälligkeit eingetreten sein, 

• Nichtleistung des Schuldners (Auftragnehmers) erfolgt sein (wobei die Leistung 
aber nicht unmöglich ist), 

• Mahnung, Klageerhebung oder Zustellung eines Mahnbescheides (§ 286 Abs. 1 
S. 2 BGB) nach Fälligkeitseintritt erfolgt sein. Der Mahnung bedarf es nicht, 
wenn 

- eine Leistungszeit nach Kalender bestimmt ist (§ 286 Abs. 2 Nr. 1 BGB). 

- der Leistung ein Ereignis vorauszugehen hat und eine angemessene Zeit für 
die Leistung in der Weise bestimmt ist, dass sie sich von dem Ereignis an 
nach dem Kalender berechnen lässt (§ 286 Abs. 2 Nr. 2 BGB). 

- der Schuldner die Leistung ernsthaft und endgültig verweigert (§ 286 Abs. 2 
Nr. 3 BGB). Befindet sich ein Software-Hersteller seit längerer Zeit mit der 
Fertigstellung einer Individualsoftware in Verzug und macht er seine weitere 
Tätigkeit von einer Abschlagszahlung des Bestellers abhängig, die höher ist 
als die nach dem Vertrag vereinbarte Vergütung, ist der Auftraggeber be- 
rechtigt, vom Werkvertrag zurückzutreten; die unbedingte Forderung nach 
einer nicht in dieser Höhe zu beanspruchenden Abschlagszahlung stellt eine 
endgültige Erfüllungsverweigerung des Unternehmers dar, die die Einhal- 
tung des § 326 BGB entbehrlich macht. 1 

- aus besonderen Gründen unter Abwägung der beiderseitigen Interessen der 
sofortige Eintritt des Verzuges gerechtfertigt ist (§ 286 Abs. 2 Nr. 4 BGB), 



i 



OLG Köln, Urt. vom 27.10.1995 - 19 U 59/95, CR 1996, 209. 
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etwa dann, wenn sich der Schuldner der Mahnung entzieht oder diese in 
sonstiger Weise verhindert. 2 

• alle im Mahnungszeitpunkt erforderlichen Mitwirkungshandlungen erbracht 
worden sind 3 und 

• Vertretenmüssen des Schuldners vorliegt (§ 286 Abs. 4 BGB). 

Checkliste zur Schadensersatzpflicht aus Pflichtverletzung bei Verzug oder 

Schlechtleistung 

• Pflichtverletzung durch Nichtleistung (Verzug) oder Schlechterfüllung, § 281 
Abs. 1 BGB. 

• Vertretenmüssen (Umkehrschluss aus § 280 Abs. 1 S. 2 BGB). 

• Alle Schäden werden erfasst: Mangelschäden aus § 280 Abs. 1, 3, 281 BGB (Ab- 
lauf gesetzter Nachfrist zur Mangelbeseitigung oder Nachlieferung notwendig), 
Mangelfolgeschäden aus § 280 Abs. 1 BGB (keine Nachfrist notwendig). Die 
Mängeltypenunterscheidung ist wegen des Fristsetzungserfordernisses weiter 
relevant. 

• Schadensersatz statt Leistung kann verlangt werden, wenn Leistung schuldhaft 
nicht oder nicht wie geschuldet erbracht ist (§ 281 Abs. 1 BGB, die zentrale An- 
spruchsgrundlage bei mangelhafter Lieferung) oder anstelle des Schadenser- 
satzanspruches. Der Ersatzanspruch entsteht nach Setzen und ergebnislosem 
Ablauf einer angemessenen Nachfrist für die Leistungserbringung, § 281 Abs. 1 
S. 1, 323 Abs. 1 BGB, wobei Ablehnungsandrohung nicht mehr erforderlich ist. 
Schadensersatz kann unter diesen Voraussetzungen auch für einen nicht er- 
brachten Leistungsteil verlangt werden; wenn der Gläubiger kein Interesse am 
Leistungsteil hat, ist Schadensersatz statt der gesamten Leistung möglich (aber 
nur, wenn Pflichtverletzung nicht unerheblich ist, § 281 Abs. 1 S. 3 BGB). 

• Verzögerungsschaden kann neben der bestehenbleibenden Leistungspflicht aus 
den §§ 280 Abs. 1, 286 BGB verlangt werden; Mahnung muss erfolgen, soweit 
nicht entbehrlich (§ 286 Abs. 2 BGB); Vertretenmüssen ist erforderlich. 

• Schlechtleistung: Bei (trotz Fristablauf) nichterbrachter Nacherfüllung (Besei- 
tigung des Mangelschadens = Mängelbeseitigung oder Nachlieferung) kann 
Schadensersatz statt der Leistung verlangt werden. Mangelfolgeschaden bei 
Nacherfüllung aus § 280 Abs. 1 BGB (ohne Fristsetzungserfordernis). 

• Aufwendungsersatz (§ 284 BGB). 

• Verzugszinsen (§ 288 Abs. 1 BGB). 

• Verletzung einer Schutzpflicht: Schadensersatz aus den §§ 282 i.V.m. 241 
Abs. 2, 280 Abs. 1 BGB. 



2 Gesetzesbegründung, BT-Drucks. 14/6040, 146. 

3 BGH, DB 1971, 2155; BGH, WM 1985, 949. 
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• „Kleiner“ Schadensersatzanspruch (für Mängel) § 281 Abs. 1 S. 1 1. Alt. BGB. 

• „Großer“ Schadensersatzanspruch (Schadensersatz statt der Leistung) § 281 
Abs. 1 S. 3 BGB. 

2. Mängelrechte des Auftraggebers aus Projektverträgen 

490 IT-Projekte umfassen meist eine Vielzahl von Einzelleistungen, die unterschiedli- 
chen Vertragstypen zuzuordnen sein können, die wiederum die Mängelrechte 
festlegen. Der Erwerb von Serverrechnern kann Kaufrecht unterliegen oder als 
Leasing Mietrecht. Die Erstellung oder Änderung von Software, aber etwa auch 
von Machbarkeitsstudien oder Feinkonzeptionen durch den Anbieter wird Werk- 
vertragsrecht zuzuordnen sein, 4 ebenso das Projektmanagement als getrennt defi- 
nierte Leistung, die allerdings nicht auf einen bestimmten Zeitpunkt hin (etwa den 
der Abnahme), sondern während der gesamten Projektdurchführung geschuldet 
wird. 

491 Die Einheit des Projekts erlaubt freilich nicht, diese und andere projektspezifische 
Leistungen vertragstypologisch völlig isoliert zu behandeln, sondern es muss ge- 
wissermaßen ein übergreifender vertraglicher „Mantel“ gefunden werden, der eine 
Vereinheitlichung der Rechtsfolgen bei Leistungsstörungen und hier insbesondere 
bei Leistungsmängeln erlaubt. Dies gelingt etwa durch Annahme eines Typen- 
kombinationsvertrags. 

a) Mängelrechte des Auftraggebers aus Werkvertrag 

492 § 633 Abs. 1 BGB verlangt - im Einklang mit dem kaufrechtlichen Mängelbe- 
griff 5 -, dass das Werk frei von Sach- und Rechtsmängeln sein muss. Nach § 633 
Abs. 2 BGB ist auf die vereinbarte Beschaffenheit bzw. ersatzweise auf die voraus- 
gesetzte oder jedenfalls gewöhnliche Verwendung abzustellen. § 633 Abs. 3 BGB 
definiert Rechtsmängel als Rechte Dritter am Werk. 

493 Ist die Werkleistung (etwa das IT-bezogene Pfhchtenheft oder die Software) man- 
gelhaft, kann der Auftraggeber die Abnahme (§ 640 BGB) verweigern, da das 
geschuldete Werk nicht vertragsgemäß ist. Nimmt der Auftraggeber die Leistung 
dennoch ab, muss er sich seine Bestellerrechte aus § 634 Nr. 1-3 BGB Vorbehal- 
ten, wenn er von Mängeln Kenntnis hat (§ 640 Abs. 2 BGB); dies gilt nunmehr 
auch bezüglich des Schadensersatzanspruches. Problematisch sind vor allem Teil- 
abnahmen, die Anbieter gerne mit Vergütungsteilzahlungen verbinden, wobei 
vielfach aber erst in der Gesamtprüfung wichtige Funktionen des abzunehmenden 



4 Zum Problem aus § 651 s. Rdn. 200. 

5 S. unten Rdn. 496. 
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Leistungs teils feststellbar sind. Ein entsprechender Abnahmevorbehalt sollte im 
Abnahmeprotokoll ausdrücklich erklärt werden. Bei komplexeren Systemen emp- 
fiehlt es sich außerdem, genau zu bezeichnen, welche Funktionen zu welchem 
Zeitpunkt für welchen Leistungsteil mit welchem Ergebnis getestet wurden. Ver- 
säumnisse können sich hier schnell bitter rächen, wenn aus einer fehlenden oder 
nicht dokumentierten Prüfung die Billigung des Kunden abgeleitet wird. 

Die kaufmännische Rügepflicht besteht auch bei Werklief erungsverträgen (§§ 381 494 
Abs. 2, 377 HGB) über Individualsoftware 6 ; sie wurde jedoch für EDV-unkundige 
Kaufleute hinsichtlich des Umfangs der Mängelschilderung auf das dem Laien 
zumutbare Maß beschränkt. Die Art des Mangels muss erkennbar sein. 7 Mängel- 
rechte aus bei einer zumutbar umfangreichen Abnahmeprüfung nicht erkennba- 
ren Mängeln bleiben unberührt (auch ohne Vorbehalt, der aber insoweit vorsorg- 
lich erklärt werden sollte). 

Weiter kann der Besteller (Auftraggeber) aus nach Abnahme entdeckten und ge- 495 
rügten Mängeln im Rahmen der gesetzlichen Mängelhaftung aus Werkvertrag 

• Nacherfüllung verlangen (§§ 634 Nr. 1, 635 BGB). Der Nacherfüllungsanspruch 
hat Vorrang vor weiteren Mängelrechten. Der Auftragnehmer ist als Werkun- 
ternehmer (anders als beim Kauf) berechtigt, zwischen Mängelbeseitigung und 
Nachlieferung zu wählen, § 635 Abs. 1 BGB. Das Nacherfüllungsverlangen - 
und damit Nachlieferung wie Mängelbeseitigung - stellt im Rahmen der Pro- 
jektdurchführung einen „Change Request“ dar, den der Anbieter ohne Kosten 
für den Auftraggeber durchzuführen hat. Hierdurch kann eine Terminverzöge- 
rung auftreten, die oft eine Anpassung des Projektplans erforderlich macht. 

Der Kunde muss dem Anbieter bei komplexen Leistungen gegebenenfalls mehr 
Spielraum für die Durchführung von Nachbesserungsarbeiten einräumen. 

Weiß der Anbieter aber, dass der Kunde dringend auf eine arbeitsfähige Lösung 
angewiesen ist, ist ein wochen- oder monatelanges Zuwarten unzumutbar 8 . In 
Projekten ist dies etwa dann der Fall, wenn der Auftraggeber selbst gegenüber 
seinen eigenen Kunden terminlich gebunden ist, z.B. aus der Verpflichtung, für 
seine Kunden eine Webpräsenz aufzubauen. 

Das Auftreten von Programmierfehlern stellt als solches noch nicht notwendig 
einen Mangel des Programmes dar, zumal bei Erstellung von Software stets mit 
Fehlern zu rechnen ist. Entscheidend ist allein, inwieweit diese Fehler die Ge- 
brauchseigenschaften der Software beeinträchtigen. 9 War im Pflichtenheft fest- 



6 OLG Celle, Urt. v. 8.11.1985 - 11 U 212/84, IUR 1986, 311. 

7 LG Köln, Urt v. 4.3.1983-90 0 112/82, IUR 1986, 315. 

OLG Düsseldorf, CR 1992, 724. 

KG Berlin, Urt.v. 30.9.1985 - 2 U 5503/83, DV-R 3, 45. 



9 
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gehalten, dass Daten jederzeit geändert werden können sollen, ist in dem Um- 
stand ein Fehler zu sehen, dass Stammdaten nur mit der Einschränkung einer 
vorherigen Großauswertung geändert werden können. 10 Aus dem Umstand, 
dass Software-Fehler nur bei der Definition (fehlerhafte Vorgaben), dem Ent- 
wurf (Design-Fehler) oder bei dem Codieren auftreten können, nicht aber erst 
später, 11 wurde zutreffend die Vermutung abgeleitet, dass Software-Fehler be- 
reits bei Gefahrübergang (mit Abnahme, §§ 644, 640 BGB) vorhanden sind. 12 
Eine Ausnahme kann allerdings für den Software-Teil Dokumentation gelten, 
in welchen Anbieter auch noch nach Übergabe der Programme Fehler einbauen 
können, wenn sie die Dokumentation erst im nachhinein erstellen. 

Auch nachträgliche Änderungen der Software im Rahmen von Fehlerbeseiti- 
gungen müssen vollständig dokumentiert werden, so dass man zumindest im 
Nachhinein weiß, was eigentlich geändert wurde. Die Änderung selbst stellt ei- 
nen Change im Sinne des Change Managements dar und ist als solcher zu be- 
handeln. 

Die mehrfache Wiederholung von Mängelbeseitigungsversuchen kann für den 
Auftraggeber unzumutbar sein, dies insbesondere, wenn die Nachbesserungs- 
versuche mit personellem und zeitlichem Mitwirkungsaufwand auf der Seite 
des Auftraggebers (oder gar seiner Kunden) verbunden ist. Abweichende Rege- 
lungen in AGB wurden bereits nach § 11 Nr. 10 d) AGBG a.F. (jetzt § 309 Nr. 8b 
dd) als unwirksam angesehen. 13 Allerdings kann für den Kunden eine Wieder- 
holung der Mängelbeseitigung einem Projektabbruch vorzuziehen sein. 

Kosten der Nacherfüllung (und insbesondere Nachbesserung) muss der Anbie- 
ter tragen, so auch alle Nebenkosten (etwa für Transport, Anfahrt, Arbeitszeit 
und Material 14 ), ebenso erforderliche Nebenarbeiten. 15 Soweit zeitlich parallel 
zur Gewährleistung außerdem Wartung und/oder Pflege vereinbart ist, darf der 
Anbieter die Beseitigung von Mängeln nicht als Wartungs- oder Pflegeleistung 
abrechnen, ist doch die Gewährleistung bereits in die ursprüngliche Vergütung 
einkalkuliert. 

Verweigern kann der Unternehmer die Nacherfüllung nach § 635 Abs. 1 BGB, 
wenn sie für ihn mit unverhältnismäßigen Kosten verbunden wäre (§ 635 Abs. 
3 BGB). Der Anbieter ist aber - schon aus seiner vertraglichen Leistungstreue- 
pflicht im Projektvertrag - gehalten, nach Möglichkeit eine temporäre oder 
dauerhafte Umgehungs- oder Ausweichlösung zu realisieren. Auch wird er zu 
berücksichtigen haben, dass Schadensersatzansprüche des Kunden bei Rücktritt 



10 LG Düsseldorf, Urt. v. 29.4.1985 - 41 O 92/84, CR 1987, 292. 

11 Dann sind allenfalls Fehler des Datenträgers denkbar. 

12 LG Coburg, Urt. v. 1.8.1984 -20 478/83, IUR 1986, 314. 

13 AG Mannheim, CR 1996, 540 = NJW-RR 1997, 560. 

14 BGH NJW 1979, 2095. 

BGHZ 58, 332, 339. 
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wegen Verweigerung der Nachbesserung zu einer deutlich höheren Kostenbe- 
lastung als eine Mängelbeseitigung (oder sogar Neuerstellung) führen können. 

• Der Besteller ist berechtigt, den Mangel selbst zu beseitigen (§§ 634 Nr. 2 1. Alt., 
637 BGB, Selbstvornahme mit Vorschusspflicht des Unternehmers, § 637 Abs. 
3 BGB) und Ersatz der erforderlichen Aufwendungen zu verlangen (§§ 634 Nr. 
2 2.Alt., 636 BGB), außer, der Unternehmer hat die Nacherfüllung zu Recht 
verweigert (§ 637 Abs. 1 BGB). Beseitigung durch den Besteller kommt bei IT- 
Projekten meist schon deshalb nicht in Betracht, weil insbesondere Änderun- 
gen an Quellcodes erstellter Programme auftraggeberseits in der Regel nicht 
durchgeführt werden können. Entweder hat der Auftraggeber bei Teilleistun- 
gen nicht die kompletten Sourcen erhalten oder er verfügt nicht über die erfor- 
derliche Fachkompetenz im Software Engineering (andernfalls hätte er die 
Software gleich selbst geschrieben) oder der Anbieter schließt bei solchen Ein- 
griffen jede Mängelhaftung aus (allein schon, weil die Auswirkungen auf andere 
Programmteile nicht absehbar sind). 

• Der Besteller kann vom Vertrag zurücktreten (§§ 634 Nr. 3 1. Alt., 636, 323, 
326 Abs. 5 BGB). Damit ist das Projekt freilich durch Abbruch beendet und der 
Kunde kein Stück seiner Problemlösung näher. Bei nur unerheblichen Mängeln 
ist der Rücktritt ausgeschlossen (§§ 634 Nr. 3, 323 Abs. 1 BGB), die anderen 
Gewährleistungsrechte bleiben unberührt. 

Scheitert der Anbieter mit der vertraglich geschuldeten Entwicklungsleistung, 
muss er im Rahmen der rücktrittsbedingten Rückabwicklung auch erhaltene 
Lizenzgebühren zurückzahlen und darf nicht seinen Entwicklungsaufwand in 
Rechnung stellen. 16 

• Der Besteller kann die Vergütung mindern (§§ 634 Nr. 3 2. Alt., 638 BGB). 
Dieses Mängelrecht lässt den Projektablauf grundsätzlich unberührt. Streit 
kann aber bei der Frage entstehen, wie der Minderungsbetrag berechnet werden 
soll. Zwar ist hier vom Gesetz ein Berechnungsverfahren vorgesehen, aber es ist 
sorgfältig zu prüfen, wie der Vergütungsanteil für den vom Mangel betroffenen 
Leistungsteil (z.B. ein Software-Modul) zu berechnen ist. Außerdem können 
mehrfache Minderungen zu Vergütungskürzungen führen, die die anbietersei- 
tige Vorfinanzierung des Projekts und regelmäßige anbieterseitige Kreditrück- 
führungen mit Projektfortschritt und damit den Projekterfolg selbst gefährden 
können. Das Minderungsrecht kann also unzweifelhaft bestehen, seine Aus- 
übung die Realisierungschancen des Projekts aber zweifelhaft werden lassen. 

• Der Besteller kann Schadensersatz verlangen (§§ 634 Nr. 4 l.Alt., 636, 280, 281, 
283, 311 a BGB) oder Ersatz vergeblicher Aufwendungen (§§ 634 Nr. 4 2. Alt., 



16 OLG Köln, Urt.v.14.2.2001 - 19 U 176/95, JurPC Web-Dok. 31/2002. 
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284 BGB). Der Besteller muss aber genau prüfen, welchen Weg er hier geht. 
Stützt er seinen Schadensersatzanspruch auf die §§ 634 Nr. 4, 281 BGB, verlangt 
er Schadensersatz statt der Leistung. Folge ist, dass der Besteller keine (weitere) 
Projektleistung mehr verlangen kann (§ 281 Abs. 4 BGB). Soll das Projekt wei- 
terlaufen können, darf er also nur Schadensersatz aus den §§ 634 Nr. 4, 280 
BGB verlangen, also neben der Leistung. 

496 Nach dem schuldrechtsmodernisierten Werkvertragsrecht laufen je nach Art des 
Werkes eine zweijährige Verjährungsfrist (§ 634 a Abs. 1 Nr. 1 BGB bei sachbezo- 
gener Werkleistung) oder eine dreijährige Frist (§§ 634 a Abs. 1 Nr. 3, 195 BGB bei 
immateriellen Werkleistungen) für Mängelrechte. 

b) Mängelrechte des Auftraggebers aus Kaufvertrag 

497 Die zeitlich unbegrenzte Überlassung von Standardsoftware gegen Einmalzahlung 
folgt Kaufrecht. Kaufrecht ist aber über § 651 BGB auch bei Erstellung individual- 
programmierter Software anwendbar (wenn § 651 als anwendbar angenommen 
wird, s. Rdn. 200 ff.); allerdings bleibt selbst dann die vereinbarte individuelle 
Erstellung geschuldet. Resultiert hieraus eine individuelle Software oder jedenfalls 
Anpassung, lässt diese sich als nichtvertretbare Sache beurteilen, also eine Sache, 
die nicht nach Zahl, Maß oder Gewicht bestimmt zu werden pflegt (arg. e § 91 
BGB); deshalb gelangen hier einzelne Bestimmungen aus dem Werkvertragsrecht 
zur Anwendung, allerdings nicht die Regelung zur Abnahme aus § 640 BGB. Des- 
halb sollte zur Sicherheit eine Abnahmeregelung (zumindest individualvertrag- 
lich) ergänzend vereinbart werden. 

(aa) Begriff des „Sachmangels" im Kaufrecht 

498 Der Begriff des Sachmangels wurde im Rahmen der Schuldrechtsmodernisierung 
neu definiert: § 434 BGB unterscheidet zwischen 

• „vereinbarter Beschaffenheit“ der Sache (§ 434 Abs. 1 S. 1 BGB), 

• bei Fehlen einer solchen Vereinbarung der „vertraglich vorausgesetzten Ver- 
wendung“ der Sache (§ 434 Abs. 1 S. 2 Nr. 1 BGB) und schließlich 

• der Eignung für „die gewöhnliche Verwendung“ sowie der für Sachen gleicher 
Art „üblichen Beschaffenheit“ (§ 434 Abs. 1 S. 2 Nr. 2 BGB). 

499 In jedem dieser Fälle stellt die Lieferung einer mangelhaften Sache eine Pflichtver- 
letzung dar (da die Leistung/Sache nicht „frei von Sach- oder Rechtsmängeln“ ist, 
§433 Abs. 1 S. 2 BGB). 

500 Auch unerhebliche Mängel begründen Mängelrechte, ausgenommen den Rück- 
tritt, der bei unerheblichen Pflichtverletzungen nicht zulässig ist (§ 323 Abs. 5 S. 2 
BGB), und den Schadensersatz statt Leistung (§ 281 Ans. 1 S. 3 BGB). Folge: Auch 
bereits ein einzelnes blinkendes Pixel oder ein (für die Programmfunktion irrele- 
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vanter) Rechtschreibfehler in einem Inline-Kommentar im Source Code kann 
Nacherfüllungs- bzw. Minderungs- oder Schadensersatzansprüche begründen, da 
es auf eine relevante Beeinträchtigung der Verwendbarkeit nicht ankommt. Aller- 
dings kann der Käufer nur den „kleinen“ Schadensersatz verlangen, nicht aber den 
„großen“, also nicht, wie erwähnt, Schadensersatz statt der Leistung. 

Eine fehlerhafte Dokumentation stellt einen erheblichen Mangel 17 der Systemleis- 501 
tung dar und damit eine Pflichtverletzung, wenn die Gebrauchstauglichkeit in der 
Regel erheblich eingeschränkt oder aufgehoben ist. 

Die vereinbarte Beschaffenheit (§ 434 Abs. 1 S. 1 BGB) ergibt sich aus dem jewei- 502 
ligen Vertrag zwischen den Parteien. Das Gesetz legt hier den subjektiven Fehler- 
begriff zugrunde, 18 der auf den Willen der Parteien abstellt, 19 nicht auf rein objek- 
tive Eigenschaften. Auf letztere ist nur zurückzugreifen, soweit subjektive 
Merkmale nicht vorliegen. 20 Die vereinbarte Beschaffenheit ergibt sich in IT- 
Projekten aus der Leistungsbeschreibung bzw. der fachlichen und technischen 
Feinspezifikation. 

Auf die vertraglich vorausgesetzte Verwendung (§ 434 Abs. 1 S. 2 Nr. 1 BGB) ist in 503 
den Fällen abzustellen, in denen Beschaffenheit nicht vollständig oder überhaupt 
nicht ausdrücklich vereinbart wird, sondern die Sache nur allgemein für einen 
bestimmten Verwendungszweck tauglich sein soll. 21 Maßgeblich ist auch hier der 
subjektive Fehlerbegriff. Eine konkludente Übereinstimmung der Parteien soll 
nach der Vorstellung des Gesetzgebers ausreichen. 22 Der Auftraggeber muss beach- 
ten, dass sich Defizite in der ausdrücklichen Leistungsspezifizierung in der Regel zu 
seinem Nachteil auswirken, da er die Beweislast für die konkludente Einigung über 
ein von ihm vermisstes Leistungsmerkmal trägt. Gelingt der Beweis nicht, kann der 
Auftraggeber in solchen Fällen auch keine Nacherfüllung verlangen. 

Auf die gewöhnliche Verwendung (§ 434 Abs. 1 S. 2 Nr. 2 BGB) ist abzustellen, 504 
wenn es an der Vereinbarung einer Beschaffenheit sowie der Voraussetzung einer 
bestimmten Verwendung fehlt. 23 Diese Mängelkategorie wird auf alle Standard- 
komponenten anzuwenden sein, die erworben werden, ohne dass die Vertragspar - 



17 OLG Hamm, Urt.v.ll. 12.1989- 31 U 37/89, CR 1990,715. 

18 Gesetzesbegründung, BT-Drucks. 14/6040,212. 

19 Da ein einseitig ausgebildeter Wille nur einer Partei freilich nicht Vereinbarungsinhalt 
wird, sondern immer zumindest eine Zustimmung der anderen Vertragspartei vorlie- 
gen muss, wäre richtiger vom „intersubjektiven“ Fehlerbegriff zu sprechen. 

20 Boerner, ZIP 200 1 , 2264, 2266. 

21 Gesetzesbegründung, a.a.O., 213. 

22 Gesetzesbegründung, a.a.O., 213. 

Westermann , NJW 2002, 241, 243. 
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teien eine bestimmte Beschaffenheit vereinbaren oder eine bestimmte Verwen- 
dung voraussetzen (typischerweise: Bestellung nach Katalog). Die gewöhnliche 
Verwendung als Maßstab bezieht sich auf einen objektiven Fehlerbegriff. Die 
Kaufsache muss hier eine Beschaffenheit aufweisen, die bei Sachen der gleichen 
Art üblich ist und die der Käufer nach der Art der Sachen erwarten kann. 24 

505 Der Verkäufer muss auch für bestimmte Sacheigenschaften einstehen, die der 
Käufer nach öffentlichen Äußerungen des Verkäufers, Herstellers oder seines 
Gehilfen in der Werbung oder bei der Kennzeichnung erwarten darf (auch, wenn 
die Äußerungen nicht Gegenstand des Verkaufsgespräches waren), außer, der 
Verkäufer kannte die Äußerung nicht und musste sie auch nicht kennen oder sie 
konnte die Kaufentscheidung nicht beeinflussen (§ 434 Abs. 1 S. 3 BGB), was der 
Verkäufer zu beweisen hat. 25 

506 Als Sachmangel gilt es auch, wenn die vereinbarte Montage durch den Verkäufer 
oder dessen Erfüllungsgehilfen als solche unsachgemäß durchgeführt wurde (§ 434 
Abs. 2 S. 1 BGB), ebenso, wenn die Montageanleitung (selbst) mangelhaft ist, au- 
ßer, die Sache konnte (trotzdem) fehlerfrei montiert werden (§ 434 Abs. 2 S. 2 
BGB, sog. „Ikea-Klausel“). Nach dieser Mängeldefinition muss der Mangel nur der 
Anleitung anhaften, während die zu montierende Sache selbst mangelfrei sein 
kann; es genügt, dass die Sache selbst nicht fehlerfrei montiert wurde. Die Be- 
stimmung wird jedoch so auszulegen sein, dass sich ein Montagemangel in der 
Verwendungseignung der Sache auswirken muss. 26 Auch wird zu verlangen sein, 
dass der Fehler in einer kundenseitigen Montage gerade durch den Fehler in der 
Anleitung begründet ist. 

Diese sog. „Ikea“-Klausel kann wohl für Anleitungen zu Aufbau und Installation 
von Netzwerken herangezogen werden, aber nicht für Bedienungsanleitungen 
oder gar Entwicklungsdokumentationen für System- und Anwendungssoftware. 
Ebenso wird das Laden und Einrichten von Software nicht als „Montage“ gelten 
können, die begrifflich eher den Zusammenbau von Teilen („Ikea“) und ver- 
gleichbare Aktivitäten umfasst. Im Wege der Nacherfüllung kann der Kunde zu- 
nächst vom Verkäufer eine ordnungsgemäße Anleitung verlangen, hilfsweise die 
Durchführung der Montage durch den Verkäufer, sowie bei Nichtnacherfüllung 
zurücktreten oder mindern und jeweils möglichen Schaden ersetzt verlangen. Die 



24 Gesetzesbegründung, BT-Drucks. 14/6040, 213. 

25 Westermann, NJW 2002, 241, 245. 

26 In diesem Sinne auch die Gesetzesbegründung, BT-Drucks. 14/6040, 215, die von einer 
zunächst mangelfrei gelieferten Sache spricht, die nur dadurch mangelhaft werde, dass 
sie unsachgemäß montiert oder aufgestellt wird, womit die Begründung offensichtlich 
einen weiten Begriff des „Montage“ zugrundelegt, der auch ein bloßes Aufstellen um- 
fasst. 
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Verweigerung wegen Unverhältnismäßigkeit muss, da Einrede, geltend gemacht 
werden. 27 

(bb) Rechtsmängel 

Sach- und Rechtsmängel werden einheitlich behandelt, da es sich bei beiden um 507 
Pflichtverletzungen handelt, weshalb der Verkäufer auch für Rechtsmängel nur bei 
Verschulden auf Schadensersatz haftet, 28 während diese Haftung bisher verschul- 
densunabhängig war. Der Verkäufer muss sich von einem Verschulden entlasten 
(§ 280 Abs. 1 S. 2 BGB). Nacherfüllungsansprüche bestehen auch bei Rechtsmän- 
geln, so etwa bei Lieferung eines Betriebssystems, für das der Anbieter kein 
Verbreitungsrecht eingeräumt erhalten hat. 

(cc) Mängelrechte des Auftraggebers aus Kauf 

Der Auftraggeber kann unter Anwendbarkeit von Kaufrecht bei Mängeln 508 

• Nacherfüllung verlangen (§§ 437 Nr. 1, 439 BGB). Nacherfüllung besteht auch 
dann, wenn der gerügte Mangel nur unerheblich ist. 29 Der Auftraggeber kann 
hier in seiner Käuferposition wahlweise Mangelbeseitigung oder Lieferung ei- 
ner mangelfreien Sache verlangen (§ 439 Abs. 1 BGB). Der Anbieter muss die 
erforderlichen Aufwendungen für die Nacherfüllung tragen (§ 439 Abs. 2 BGB). 
Werden Nachbesserungen nur gegen Bezahlung angeboten, stellt dies eine 
Verweigerung kostenloser Mängelbeseitigung dar. 30 

Verweigern kann der Anbieter die Nacherfüllung, wenn sie nur mit unverhält- 
nismäßigem Aufwand möglich ist (§ 439 Abs. 3 S. 1 BGB). Als fehlgeschlagen 
gilt eine Nachbesserung (Mängelbeseitigung) nach dem erfolglosen zweiten 
Versuch, wenn sich nicht aus der Art der Sache oder des Mangels oder dem 
Verhalten des Verkäufers etwas anderes ergibt (§ 440 S. 2 BGB). 

Bei Nachlieferung kann der verkaufende Anbieter die mangelhafte Sache zu- 
rückverlangen (§§ 346-348 BGB). Ebenso muss der Käufer tatsächlich gezogene 
Nutzungen herausgeben (§ 346 Abs. 1 BGB). Bei Software wird die Rückgabe 
freilich zumeist wenig Sinn machen, vielmehr durch Installieren des Update die 
vorhandene Software auf dem Speicher „überschrieben“ werden. 

Bei Verweigerung, Pehlschlagen oder Unzumutbarkeit der Nacherfüllung (wegen 509 
der Nacherfüllungskosten) kann der Auftraggeber 



27 Huber, NJW 2002, 1004, 1007. Nach Huber ist bei § 439 Abs. 3 BGB ein Verschulden 
des Verkäufers ebenso zu berücksichtigen wie das Leistungsinteresse des Gläubigers. 

28 Rolland, Regelungsgehalte der Vorschläge zur Überarbeitung des Schuldrechts, in: 
Grundmann/Medicus/Rolland, Kaufgewährleistung, 15, 22. 

29 Gesetzesbegründung, BT-Drucks. 14/6040,231. 

OLG München, Urt.15.2.1989 - 27 U 386/88, CR 1990, 646. 
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• vom Vertrag zurücktreten (§§ 437 Nr. 2 1. Fall, 440, 323, 326 Abs. 5 BGB), 
wenn eine angemessene Frist zur Nacherfüllung gesetzt wurde und abgelaufen 
ist (§ 323 Abs. 1 BGB) oder die Fristsetzung entbehrlich war (§ 440 BGB). Diese 
Fristsetzung bezieht sich auf den Erfüllungsanspruch des Käufers aus § 433 
Abs. 1 S. 2 BGB, der allerdings in § 439 BGB zu einem Nacherfüllungsanspruch 
modifiziert ist. 31 Die verkäuferseitige Nacherfüllung erhält somit Vorrang vor 
dem käuferseitigen Rücktritt. 32 Der Anbieter hat damit ein vorgängiges Recht 
zur „zweiten Andienung“. 33 Das Rücktrittsrecht ist Gestaltungsrecht. Es bindet 
den Käufer nach der Ausübung 34 und kann deshalb nicht widerrufen werden, 35 
was naturgemäß eine sorgfältige Prüfung und Rechtsberatung vor Entschei- 
dung über einen Rücktritt erforderlich macht. Jedoch kann auch nach Erklä- 
rung des Rücktrittes noch Schadensersatz geltend gemacht werden kann. 36 

• den Kaufpreis mindern (§§ 437 Nr. 2 2. Fall, 441 BGB). Minderung ist auch bei 
Rechtsmängeln möglich, 37 ebenso bei Unerheblichkeit eines Mangels; dies folgt 
daraus, dass in § 441 der § 323 Abs. 5 BGB für nicht anwendbar erklärt wird. 38 
Auch das Minderungsrecht ist Gestaltungsrecht. 39 Minderung setzt erfolglose 
Fristsetzung zur Nacherfüllung voraus, 40 kann also nicht wirksam ausgeübt 
werden, bevor der Verkäufer eine Nacherfüllungsmöglichkeit eingeräumt er- 
halten hat. Minderung ist damit nur möglich, wenn die Rücktrittsvorausset- 
zungen erfüllt sind (wie sich aus der Formulierung „Statt zurückzutreten ..." § 
in § 441 ergibt). 41 Fristsetzung ist aber unter den Voraussetzungen der §§ 440, 
323 Abs. 2 BGB entbehrlich, also dann, wenn der Verkäufer die Nacherfüllung 
ernsthaft und endgültig verweigert (§ 323 Abs. 2 Nr. 1 BGB), sie nicht innerhalb 
der gesetzten angemessenen Frist bewirkt und der Käufer im Vertrag den Fort- 
bestand seines Leistungsinteresses an die Rechtzeitigkeit der Nacherfüllung ge- 
bunden hat (§ 323 Abs. 2 Nr. 2 BGB) oder besondere Umstände vorliegen, die 
unter Abwägung der beiderseitigen Interessen den sofortigen Rücktritt recht- 
fertigen (§ 323 Abs. 2 Nr. 3 BGB). 

Ausgeschlossen ist das Minderungsrecht bei alleiniger oder überwiegender 
Verantwortlichkeit des Gläubigers für den Rücktrittsgrund oder Annahmever- 



31 Gesetzesbegründung, a.a.O., 221. 

32 Gesetzesbegründung, BT-Drucks. 14/6040, 221 unter Hinweis auf die Regelung eines 
entsprechenden Stufenverhältnisses in Art. 3 Abs. 3 S. 1 RL. 

33 Hoffmann, ZRP 2001, 347, 349. 

34 Gesetzesbegründung, BT-Drucks. 14/6040, 221. 

35 Gesetzesbegründung, BT-Drucks. 14/6040, 221. 

36 Gesetzesbegründung, BT-Drucks. 14/6040, 221. 

37 Gesetzesbegründung, a.a.O., 234. 

38 Gesetzesbegründung, BT-Drucks. 14/6040, 235. 

39 Gesetzesbegründung, BT-Drucks. 14/6040, 223. 

40 Gesetzesbegründung, a.a.O., 234. 

Gesetzesbegründung, a.a.O., 235. 
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zug des Gläubigers bei Eintritt des Rücktrittsgrundes oder Kenntnis des Käufers 
vom Mangel (§ 442 BGB). 

• Neben Rücktritt und Minderung kann vom Käufer Schadensersatz (§§ 437 Nr. 

3 2.Alt., 440, 280, 281, 283, 311 a BGB) oder Ersatz vergeblicher Aufwendun- 
gen (§§ 437 Nr. 3 2. Alt., 284 BGB) verlangt werden. Vorausetzung ist, dass der 
Verkäufer eine Leistung „nicht wie geschuldet erbringt“ (Pflichtverletzung, § 

281 Abs. 1 BGB). Der Schadensersatzanspruch setzt Vertretenmüssen voraus 
(arg. e § 280 Abs. 1 S. 2 BGB). Kein Anspruch auf Schadensersatz statt Leistung 
besteht bei unerheblicher Pflichtverletzung (§ 281 Abs. 1 S. 3 BGB). 

Der Verkäufer haftet, da er Mängelfreiheit als Teil der Erfüllungspflicht schuldet, 510 
aus den §§281, 283 BGB 

• für Mangelschäden 42 (etwa Reparaturkosten 43 , mangelfeststellungsbezogene 
Gutachterkosten 44 , verbleibender Minderwert 45 , Nutzungsausfall während der 
Reparatur 46 und Gewinnentgang 47 , Betriebsstörung, 48 Betriebsausfallschaden 
durch verzögerte Inbetriebnahme 49 (!)). 

• und aus § 280 Abs. 1 BGB für Mangelfolgeschäden, 50 also Schäden an anderen 
Rechtsgütern des Käufers. Schadensersatz statt Leistung geht (wie bisher Scha- 
densersatz wegen Nichterfüllung) auf das positive Interesse, weshalb der Kunde 
so zu stellen ist, wie er stünde, wenn der Vertrag ordnungsgemäß erfüllt wor- 
den wäre. 51 

• Bei Gattungssachen besteht eine verschuldensunabhängige Einstandspflicht aus 
übernommenem Beschaffungsrisiko (§§ 280 Abs. 1, 276 BGB). 

Das strenge Klauselverbot des § 309 Nr. 7 BGB (Verletzung des Lebens, des Kör- 511 
pers, etc.) ist zu beachten. Ersatzfähige Schäden sind etwa Verzögerungsschäden 
(über § 280 Abs. 2 BGB) und Schäden durch Produktionsausfall (§ 280 Abs. 1 
BGB, „Betriebsausfallschäden“). 



42 Gesetzesbegründung, BT-Drucks. 14/6040,224. 

43 BGHZ 77, 218. 

44 BGH NJW 1978, 224 lf. 

45 BGH, a.a.O.; Palandt/Heinrichs, Bürgerliches Gesetzbuch, § 276 Rdn. 110. 

46 BGH NJW 1978, 2242. 

47 BGHZ 77, 218. 

48 Flessner, Richtlinie und Reform - Die Einpassung der Kaufgewährleistungs-Richtlinie 
ins deutsche Recht, in: Grundmann/Medicus/Rolland, Kaufgewährleistung, 233, 244. 

49 Gesetzesbegründung, BT-Drucks. 14/6040, 224: Anspruch bereits aus § 280 Abs. 1 BGB, 
unabhängig von Verzugsvoraussetzungen des § 281 Abs. 1 BGB einschließlich An- 
spruch auf Ersatz von Rechtsverfolgungskosten. 

50 Gesetzesbegründung, BT-Drucks. 14/6040,224. 

Boerner, ZIP 2001, 2264, 2272. 
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512 Die Schadensersatzhaftung des Verkäufers erfasst generell Pflichtverletzungen und 
besteht auch bei erklärtem Rücktritt, weshalb etwa der Käufer bei nichtbeseitigtem 
Mangel neben Rücktritt aus einem trotz Rücktritt bestehenden Schadensersatz- 
sanspruch Ersatz des Schadens aus Deckungskauf verlangen kann. 52 Sie setzt aber 
Vertretenmüssen des Verkäufers und Ablauf einer käuferseits gesetzten Frist 
(§ 281 Abs. 1 S. 1 BGB) voraus. 53 Mit Geltendmachen des Anspruches auf Scha- 
densersatz erlischt der Leistungsanspruch, nicht bereits mit Ablauf der zu setzen- 
den Frist. 

513 Der Auftraggeber trägt die Beweislast für das Vorhandensein von Mängeln erst ab 
dem Zeitpunkt, zu dem er die Kaufsache als Erfüllung angenommen hat (Grund- 
satz des § 363 BGB). Eine solche „Annahme“ wird erst nach geschuldeter Einwei- 
sung und/oder Erprobung anzunehmen sein. 54 

514 Verjährung kaufvertraglicher Mängelrechte beginnt mit Ablieferung der Kaufsa- 
che und läuft zwei Jahre (§ 438 Abs. 2 BGB). Eine Kaufsache gilt dann als „abgelie- 
fert“, wenn sie vom Verkäufer in Erfüllungsabsicht derart in den Machtbereich des 
Käufers gebracht wird, dass dieser sie auf das Vorhandensein von Mängeln unter- 
suchen kann. 55 Maßgeblicher Zeitpunkt ist die Einräumung der Sachherrschaft, 
nicht erst mit Probeläufen oder einer Einweisung. Das gilt für die getrennte Anlie- 
ferung der Software auf Datenträger, aber auch die Lieferung eines Rechners mit 
auf Festplatte installiertem (OEM-) Programm und das Ausliefern mittels Online- 
Download. Das Programm muss also vollständig installiert und lauffähig sein, 
wenn (Vor-) Installierung geschuldet ist. Eine Programmsperre muss deaktiviert 
bzw. eine geschuldete Funktionalität freigeschaltet sein. Bei einem „Rollout“ (Aus- 
lieferung und Installation) größerer Systeme ist bei zeitlicher Streckung auf die 
Auslieferung des einzelnen Rechners/Programms abzustellen, es sei denn, die 
Nutzung ist als einheitliche, etwa im Netzwerk, definiert. 

515 Bei Vereinbarung kann auch zunächst das Aufbauen eines Testsystems vorgese- 
hen sein, in dem sich der Kunde mit dem Produkt vertraut macht und einzelne 
Integrations-, Performance- und Lasttests durchführt. Gleiches gilt für eine Pilo- 
tierung, die neben dem produktiven Betrieb einige Applikationen unter realen 
Bedingungen testet. 

516 Im Rollout gehen dann auf der dritten Stufe alle vorgesehenen Applikationen auf 
das neue System über, wobei hier die Kundenmitwirkung besonders intensiv ist. 



52 Westermann, NJW 2002, 241, 249. 

53 Gesetzesbegründung, BT-Drucks. 14/6040, 225. 

54 Palandt/Thomas, Bürgerliches Gesetzbuch, § 363. 

BGH, Urt.v. 22.12.1999 - VIII ZR 299/98, NJW 2000, 1415, 1416 = CR 2000, 207. 



55 




E.2. Mängelrechte des Auftraggebers aus Projektverträgen 



177 



Testsystem-Stellung, Pilotierung und Rollout können hier, auch bei Kaufsystemen, 
eine eigenständige werkvertragliche Leistung darstellen. Der Roll-out kann bei 
Anwendungen mit vielen Benutzern logistisch komplex sein und einen erhebli- 
chen Planungs- und Koordinierungsaufwand erfordern. Zu berücksichtigen sind 
alle Installationen, die Übergabe der jeweils zugehörigen Dokumentationen (Be- 
nutzerhandbücher) und die erforderlichen Einweisungen. 56 

Hat sich der Verkäufer zur Aufstellung bzw. Installation eines Systems verpflich- 517 
tet, wird dem Käufer erst nach Vollendung der entsprechenden Arbeiten die Mög- 
lichkeit eröffnet, die Kaufsache zu untersuchen. Damit liegt die Ablieferung erst in 
der Vollendung dieser vereinbarten Arbeiten 57 . Bei vereinbarter Einweisung in die 
Systemnutzung ist die Ablieferung erst anzunehmen, wenn die Einweisung been- 
det ist. Die Ablieferung setzt außerdem die Übergabe der zugehörigen Handbü- 
cher voraus 58 . Wurden diese nicht geliefert, ist Ablieferung nicht möglich, sondern 
die Lieferpflicht zumindest teilweise nichterfüllt. Das gilt aber nicht, wenn nur 
Online-Hilfefunktionen fehlen 59 . Wurde ein Programmpaket ausgeliefert, aus dem 
je nach Vereinbarung bestimmte Funktionalitäten freizuschalten sind, so kann 
Ablieferung erst mit diesem Freischalten angenommen werden. Im IT-Projekt- 
vertrag (oder im Leistungsschein hierzu) sollte diese Freischaltverpflichtung ge- 
nau für Zeitpunkt und Funktionalitäten vereinbart werden. 

c) Haftung aus Garantie 

Der Verkäufer haftet verschuldensunabhängig aus Garantieübernahme für eine 518 
Beschaffenheit oder Haltbarkeit (§ 443 BGB), deren Verjährung sich nicht über 
§ 438 BGB bestimmt, sondern über die §§ 195 ff BGB, weshalb Garantiehaftung mit 
Schluss des Jahres beginnt (§ 195 Abs. 1 BGB), in dem der Anspruch entstanden ist 
und der Gläubiger Kenntnis erlangt hat oder erlangen musste. Ein Sachmangel liegt 
vor, wenn die Sache nicht die garantierte Beschaffenheit aufweist (§ 434 Abs. 1 S. 1 
BGB). Die garantierte Beschaffenheit entspricht der vereinbarten Beschaffenheit. 

Der Verkäufer haftet auf Schadensersatz nach § 280 Abs. 1 BGB, wenn die garan- 
tierte Beschaffenheit nicht vorliegt. Auf einen Ausschluss der Haftung für eine Ga- 
rantie kann sich der Verkäufer nicht berufen (§ 444 BGB); dies gilt auch für Indivi- 
dualverträge. 60 Die Garantie im Sinne des § 443 BGB wird als selbständiger Vertrag 
verstanden, den auch ein Dritter anbieten bzw. abschließen kann. 61 



56 Heilmann/ Etzel/ Richter, IT-Projektmanagement, 185. 

57 So ausdrücklich der BGH, Urt.v. 22.12.1999, a.a.O., 1417; LG Tübingen, Urt.v.21.5.1987 
- 1 HO 23/86, CR 1988, 306f. 

58 BGH, Urt.v.4.11.1992 - VIII ZR 165/91, NJW 1993, 461. 

59 BGH, Urt.v.22. 12.1999, a.a.O., 1416. 

60 Westermann, NJW 2002, 241, 247. 

Westermann, NJW 2002, 241, 248. 
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519 In Einkaufs- AGB unwirksam dem BGH 62 zufolge ist eine Regelung, nach der der 
Lieferant auch für unverschuldete Rechtsmängel einzustehen hat. Nach § 307 Abs. 
2 Nr. 1 BGB könne nämlich eine Schadensersatzpflicht nur auf Verschulden beru- 
hen. Eine verschuldensunabhängige Schadensersatzhaftung komme nur in Be- 
tracht, wenn der Verkäufer für die Beschaffenheit der Kaufsache eine Garantie 
übernommen hat, nicht aber ohne eine solche Verpflichtung allein aus der gesetz- 
lichen Verkäuferhaftung. 

d) Mängelrechte des Auftraggebers aus Mietvertrag 

520 Mietrecht gewinnt für IT-Projekte Bedeutung, wenn erstellte Leistungen zeitlich 
begrenzt überlassen bzw. in sonstiger Weise zur Nutzung bereitgehalten werden. 
Typische Beispiele sind das Verfügbarmachen von Anwendungen (Application 
Service Providing) oder von Speichernetzwerken (Storage Area Networks, SANs). 

(aa) Anspruch auf Erhaltung der Funktionsfähigkeit der Mietsache - Mängelbeseitigung 

521 Den Vermieter trifft eine gesetzliche Erhaltungspflicht. Er muss vermietete Syste- 
me oder Software bei Auftreten von Mängeln wieder in den vertragsgemäßen 
Zustand versetzen und in diesem erhalten (§ 535 Abs. 1 S. 2 BGB). Die Erhal- 
tungspflicht ist Hauptleistungspflicht, besteht während der gesamten Vertrags- 
laufzeit und begründet einen mieterseitigen Erfüllungsanspruch. Bei Nichtbeseiti- 
gung hat der Kunde einen Anspruch aus Nichterfüllung des Vertrages (§§ 320, 322 
BGB bzw. § 323 BGB), 63 der im Mietrecht aber gesondert geregelt wird: 

Mängelbeseitigung durch den vermietenden Anbieter 

522 Der Erhaltungspflicht korrespondiert ein Mängelbeseitigungsanspruch des Mie- 
ters. Er kann (abgesehen von Fällen der Kenntnis der Mängel, § 536 b BGB) aus 
Mietvertrag jederzeit die Beseitigung von Mängeln der Mietsache, also von Hard- 
ware und/oder Software verlangen (§ 535 Abs. 1 S. 2 BGB). Der Anbieter muss 
während der gesamten Vertragsdauer dafür sorgen, dass die überlassenen Pro- 
gramme und/oder Systeme mängelfrei funktionieren. Diese Verpflichtung gilt 
uneingeschränkt auch für Software. Der Anbieter kann sich nicht darauf berufen, 
völlig fehlerfrei funktionierende Software könne es nicht geben. Er muss dann 
auch für Schäden aus seltenen, vorher nicht ausgetesteten Fehlerkonstellationen 
haften. 64 Grundsätzlich muss der Vermieter den Mieter von durchzuführenden 
Mängelbeseitigungsarbeiten rechtzeitig benachrichtigen und notwendige Arbeiten 
so ausführen, dass der Mieter so wenig wie möglich in seiner EDV-Nutzung beein- 
trächtigt wird. Kann durch die bzw. während der Reparatur die Anlage jedoch nur 
eingeschränkt genutzt werden, liegt auch aus diesem Grunde eine mögliche Ein- 



62 BGH, Urt.v.5. 10.2005 - VIII ZR 16/05, CR 2006, 221. 

63 BGHZ 84, 42. 

64 Ebenso Brandi-Dohrn, CR 1986, 63, 67 m. w. N. 
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Schränkung der Gebrauchsfähigkeit dieser Anlage vor, die wiederum den Mieter 
berechtigt, den Mietzins angemessen für den Zeitraum der Reparatur zu reduzie- 
ren bzw. gegebenenfalls Schadensersatzansprüche geltend machen. 

Eine unerhebliche Minderung der Tauglichkeit begründet (anders als bei Kauf) 523 
keine Mieterrechte (§ 536 Abs. 1 S. 3 BGB). Allerdings bleibt die Haftung aus Ver- 
letzung einer Eigenschaftszusicherung auch dann unberührt, wenn die Tauglich- 
keitsminderung unerheblich ist (arg. e § 536 Abs. 2 BGB). 

Mängelbeseitigung durch den Auftraggeber 

Der Mieter kann einen Mangel selbst beseitigen und vom Vermieter Ersatz der 524 
erforderlichen Aufwendungen verlangen, 

• wenn der Vermieter mit der Mängelbeseitigung (Mahnung durch den Mieter) 
in Verzug (§ 284 BGB) kommt (§ 536 a Abs. 1, 3. Fall und Abs. 2 BGB). Dieser 
Erstattungsanspruch verjährt in sechs Monaten nach Beendigung des Mietver- 
hältnisses (§ 548 Abs. 1 BGB). Bei Software wird Mängelbeseitigung durch den 
Mieter in der Regel nicht in Betracht kommen, da der Quellcode nur zeitlich 
begrenzt überlassener Software für den Kunden meist nicht verfügbar ist. Die 
Schadensersatzhaftung des Vermieters aus Verzug mit der Mängelbeseitigung 
setzt Verschulden voraus, da ohne Verschulden Verzug nicht möglich ist (§ 285 
BGB). Hierin besteht eine Abweichung zum werkvertraglichen Selbstvornah- 
merecht des § 637 BGB, das nur Fristablauf, aber nicht Verzug verlangt. 

• wenn die umgehende Beseitigung des Mangels zur Erhaltung oder Wiederher- 
stellung des Bestandes der Mietsache notwendig ist (§ 536 a Abs. 2 Nr. 2 BGB, 
„Notfallklausel“). 

(bb) Minderung des Mietzinses 

Der Mieter kann die Vergütung mindern, wenn das überlassene System oder eine 525 
sonstige Mietsache aufgrund eines Mangels nicht oder nur erheblich einge- 
schränkt vertragsgemäß genutzt werden können. In diesem Fall braucht er - un- 
abhängig vom Vertretenmüssen des Anbieters - für den Zeitraum der Beeinträch- 
tigung nur einen verminderten oder überhaupt keinen Mietzins zu bezahlen. 
Gleiches gilt, wenn der Mietsache eine zugesicherte Eigenschaft fehlt (§§ 536 
Abs. 2 i.V.m. Abs. 1 BGB). Im Mietrecht gibt es also weiterhin Haftung für zugesi- 
cherte Eigenschaften. Die mietrechtliche Minderung ist eine rechtsvernichtende 
Einwendung; ihre Wirkung tritt kraft Gesetzes ein 65 , im Kaufrecht ist die Minde- 
rung ein auszuübendes Gestaltungsrecht, dessen Wirkung also erst mit Ausübung 
eintreten kann. 



65 



Palandt /Weidenkaff, Bürgerliches Gesetzbuch, § 536 Rdn. 1. 
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526 Soweit die Tauglichkeit zum Gebrauch aufgehoben ist, ist der Mieter von der Ent- 
richtung der Miete befreit (§ 536 Abs. 1 S. 1 BGB). Bei Minderung der Tauglichkeit 
ist die Miete „angemessen herabzusetzen“ (§ 536 Abs. 1 S. 2 BGB). Der Mieter muss 
die tatsächliche Zahlung entsprechend summenmäßig reduzieren oder zuviel vor- 
ausbezahlten Mietzins über Bereicherungsrecht (§ 812 BGB) zurückverlangen. 66 

(cc) Schadensersatzanspruch aus Zusicherungsverletzung 

527 Der Mieter kann Schadensersatz verlangen, wenn der Mietsache eine zugesicherte 
Eigenschaft (Musterbeispiel: Aufwärtskompatibilität zu Erweiterungsgeräten 67 oder 
Schnittstellenkompatibilität zu anderen Programmen) fehlt (vgl. §§ 536 Abs. 2 
i.V.m. Abs. 1 BGB). Im Fall einer Zusicherungsverletzung (die es begrifflich im 
Mietrecht - anders als im Kaufrecht - weiterhin gibt) muss die Gebrauchstauglich- 
keit nicht erheblich eingeschränkt sein. Der Anbieter muss mit seiner Zusiche- 
rungserklärung ausdrücklich dafür einstehen wollen, dass die behauptete Beschaf- 
fenheit auch tatsächlich vorliege und er die Folgen aus Fehlen oder Wegfall der 
zugesicherten Eigenschaften trage. Bloße Eigenschaftsbeschreibungen stellen keine 
solche haftungsbegründende Zusicherung dar. 

(dd) Schadensersatzanspruch des Mieters aus Nichterfüllung 

528 Der Mieter kann bei Mangelhaftigkeit der Mietsache Schadensersatz wegen Nicht- 
erfüllung des Vertrages vom Vermieter verlangen, 

• wenn der Mangel bereits anfänglich bei Vertragsschluss vorhanden war (§ 536 a 
Abs. 1,1. Fall BGB). Hier haftet der Vermieter verschuldensunabhängig aus sei- 
ner Erfüllungsverpflichtung auf Schadensersatz. Der Mieter muss nachweisen, 
dass der behauptete Mangel auch bereits bei Vertragsabschluss vorhanden war. 68 
Der Mangel muss noch nicht aufgetreten sein. Es genügt, dass die Gefahrenquelle 
vorhanden ist. 69 Die strenge verschuldensunabhängige Haftung des Vermieters 
für anfängliche Mängel entspricht dem Grundsatz, das Risiko demjenigen zuzu- 
ordnen, der es besser beherrschen kann. 70 Jedoch wird das Abbedingen dieser 
Vermieterhaftung auch in Formularverträgen als wirksam angesehen. 71 Hier 
muss der Kunde prüfen, ob diese Risikoverlagerung für ihn tragbar erscheint o- 
der zumindest versucht werden sollte, eine Haftungspauschale auszuhandeln, die 
die typischerweise erwartbaren Schäden abdeckt. In der Praxis hat die Haftung 
für anfängliche Mängel nur eine geringe Bedeutung. 



66 S.allg. Palandt /Putzo, Bürgerliches Gesetzbuch, § 537 Rdn. 23. 

67 Die Beschreibung als 100% kompatibel bei Kauf galt als Zusicherung (LG Mannheim, 
Urt.v.10.4. 1987 -21 0 2/87, Zahrnt DV-R 4, 337), jetzt als Beschaffenheitsgarantie. 

68 Palandt /Putzo, Bürgerliches Gesetzbuch § 538 Rdn. 2. 

69 OLG München NJW-RR 1990, 1099. 

70 BGH NJW 1971, 424. 

BGH NJW-RR 1991,74. 
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• wenn der Mangel später in Folge eines Umstandes entsteht, der vom Vermieter 
zu vertreten ist (§ 536 a Abs. 1, 2. Fall BGB). Dies begründet nicht eine ver- 
schuldensunabhängige gesetzliche Garantiehaftung, sondern nur eine verschul- 
densabhängige Schadensersatzhaftung. 

Der Mieter kann denjenigen Schaden ersetzt verlangen, der ihm durch die Ein- 529 
Schränkung der Gebrauchstauglichkeit der Mietsache entstanden ist. Dazu gehö- 
ren auch Mängelbeseitigungskosten (Personalkosten, Zeitaufwand, Bereithal- 
tungskosten, Kosten aus Anmietung einer Ersatzsache), Vertragskosten (bei Kauf 
§ 467 S.2 BGB) und entgangener Gewinn 72 (vgl. § 252 BGB). Der Vermieter haftet 
(aus seiner Garantiehaftung) auch für Mängelfolgeschäden (z. B. Datenverluste) 
und Begleitschäden 73 . 

Der Mieter muss alle Anspruchsvoraussetzungen beweisen, ausgenommen das 530 
Verschulden des Vermieters. 74 Zu beachten ist freilich, dass § 536 a BGB nicht 
darauf abstellt, wann ein Mangel (erkennbar) auftritt, sondern vielmehr auf den 
Zeitpunkt, zu dem der Mangel entsteht. 

(ee) Fristlose Kündigung 

Der Mieter kann den Mietvertrag fristlos kündigen, wenn ihm der Gebrauch des 531 
gemieteten Systems ganz oder teilweise nicht rechtzeitig gewährt oder wieder 
entzogen wurde (§ 543 Abs. 2 Nr. 1 BGB). Der Mieter muss dem Vermieter aber 
zunächst eine Frist setzen, innerhalb derer dieser Abhilfe schaffen kann (§ 543 
Abs. 3 S. 1 BGB). 

Weitere Checklisten 
Checkliste zum Rücktritt 

• Voraussetzung: Pflichtverletzung (bei nicht oder nicht vertragsgemäß erbrach- 
ter Leistung § 323 BGB im gegenseitigen Vertrag, nämlich Leistungsverzöge- 
rung oder Schlechtleistung; bei Verletzung einer Pflicht nach § 241 Abs. 2 BGB, 

§ 324 BGB, hier keine Fristsetzung erforderlich). 

• Bei Schlechtleistung darf Pflichtverletzung nicht unerheblich sein (§ 323 Abs. 5 
S.2 BGB). 

• Bei Teilleistung darf Gläubiger an Teilleistung kein Interesse haben (§ 323 Abs. 

5 S. 1 BGB). Gesamtwandlungsvoraussetzung § 469 BGB a.F. ist entfallen (!). 

• Verschulden des Rücktrittsgegners nicht erforderlich (wohl aber für Schadens- 
ersatz). 



72 BGH LM § 537, Nr. 12/13; BGH NJW-RR 195, 715. 

73 BGH NJW 1971, 424; vgl. Palandt /Putzo, Bürgerliches Gesetzbuch, § 538 Rdn. 5. 

74 BGH NJW 1964, 33. 
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• Schadensersatz auch neben Rücktritt möglich (§ 325 BGB). 

• Fristsetzung ist erforderlich, wenn kein Fall der Entbehrlichkeit vorliegt (§ 323 
Abs. 2 BGB). Verzug (i.S.d. §§ 284, 285 BGB a.F. mit Vertretenmüssen) muss 
nicht eingetreten sein. Frist muss ergebnislos abgelaufen sein. 

• Mit Ablauf der Nachfrist erlischt nicht der Erfüllungsanspruch, sondern erst, 
wenn der Gläubiger Schadensersatz statt Leistung verlangt oder Rücktritt er- 
klärt. 

• Ablehnungsandrohung nicht erforderlich, Ablehnungserklärung auch nicht, da 
diese in Rücktrittserklärung enthalten ist. 

• Keine alleinige oder überwiegende Verantwortlichkeit des Gläubigers für den 
Rücktrittsgrund, kein Annahmeverzug des Gläubigers bei Eintritt des Rück- 
trittsgrundes (§ 323 Abs. 6 BGB). 

• Bei Sachmängeln Rücktritt nur bei erheblichem Mangel (= erhebliche Pflicht- 
verletzung, § 323 Abs. 5 S. 2 BGB); bei unerheblichem Mangel nur Minderung 
(§§ 437 Nr. 2, 441 BGB) oder „kleiner“ Schadensersatz (§§ 437 Nr. 3, 280 Abs. 1, 
281 Abs. 1 S. 1 BGB) bei Vertretenmüssen. 

• Rückgewährverhältnis nach den §§ 346 ff BGB, Herausgabe der Nutzungen, 
Wertersatz (aber nicht für normale Abnutzung), auch für Ingebrauchnahme 
durch Verbraucher (§ 347 Abs. 3 S. 1 BGB). Mangelbedingte Minderung des 
Wertes des Gegenstandes ist vom Wertersatz abzuziehen. 75 

Checkliste: Pflichtverletzung 

• Sonderverbindung zwischen Anbieter und Kunden aus Vertrag oder aus gesetz- 
licher Schutzpflicht (Schuldverhältnis § 241 Abs. 1 BGB) 

• Verletzung einer Pflicht (§ 281 Abs. 1 S. 1 BGB) oder Nebenpflicht oder 
Schutzpflicht aus § 241 Abs. 2 BGB 

• Vertretenmüssen (§ 281 Abs. 1 S. 2 BGB), Vorsatz oder Fahrlässigkeit (§ 276 
BGB) 

• Schaden 

• Beweislastverteilung nach Gefahrenbereichen 

Checkliste generell zu Schadensersatzansprüchen aus Pflichtverletzung 

• § 280 BGB umfasst alle Schadensersatzansprüche; Ausnahme: Schadensersatz 
aus Unmöglichkeit der Leistung: §§ 275, 311 a Abs. 2 BGB 

• Vertretenmüssen 

• Schuldner muss sich von Vertretenmüssen entlasten 



75 



BR-Stellungnahme, BR-Drucks. 338/01 v. 13.7.2001, 40f. 
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Die frühere positive Vertrags- bzw. Forderungsverletzung wird in § 280 Abs. 1 
BGB als Form der Pflichtverletzung erfasst. 

Checkliste zur Verletzung sonstiger Pflichten 

• Verletzung einer sonstigen (nicht leistungsbezogenen) Pflicht, § 282 BGB bzw. 

§ 241 Abs. 1 S. 1 BGB 

• Unzumutbarkeit der Leistung für den Gläubiger (Interessenabwägung, Ab- 
mahnung) 

• Fristsetzung nicht erforderlich, da kein Leistungsanspruch 

• Anspruch auf Schadensersatz statt Leistung 

• Verschulden, § 280 Abs. 1 S. 2 BGB, oder Garantie, § 276 Abs. 1 S. 1 BGB 

• Haftung auf Erfüllungs-/positives Interesse 

3. Verschulden bei Vertragsschluss (culpa in contrahendo) 

Bereits in der Phase der Vertragsverhandlungen kann eine Haftung der verhan- 532 
delnden Parteien entstehen. Eine solche Haftung setzt aber voraus, dass eine Partei 
auf Erreichen eines bestimmten Verhandlungsergebnisses verrauen durfte. 

Gegründet wird die Haftung auf ein gesetzliches Schuldverhältnis. 76 Dieses ent- 533 
steht „im Vorfeld eines Vertrages“ 77 durch Aufnahme von Vertragsverhandlungen 
(§311 Abs. 2 Nr. 1 BGB) oder durch Anbahnung eines Vertrages, bei dem der eine 
Teil im Hinblick auf eine etwaige rechtsgeschäftliche Beziehung dem anderen Teil 
die Möglichkeit zur Einwirkung auf seine Rechte, Rechtsgüter und Interessen 
gewährt oder ihm diese anvertraut (§ 311 Abs. 2 Nr. 2 BGB) oder durch ähnliche 
geschäftliche Kontakte (§ 311 Abs. 2 Nr. 3 BGB). Nr. 1 begründet Haftung aus 
dem Beginnen und Führen von Vertragsverhandlungen, Nr. 2 hingegen aus dem 
Eröffnen potentieller Geschäftsbeziehung. 78 Als ähnliche Kontakte im Sinne von 
Nr. 3 werden solche angesehen, die zur Vorbereitung der Anbahnung des Vertra- 
ges dienen. 79 

Grundlage einer Ersatzpflicht aus § 311 Abs. 2 BGB ist § 241 Abs. 2 BGB in Ver- 534 
bindung mit § 280 BGB. 80 Die Sachwalterhaftung etwa von Sachverständigen oder 
anderen „Auskunftspersonen“ wird in § 311 Abs. 3 S. 2 BGB erfasst. 81 Zu dieser 



76 Gesetzesbegründung, a.a.O. 162. 

77 Gesetzesbegründung, a.a.O., 162. 

78 Gesetzesbegründung, BT-Drucks. 14/6040, 163. 

79 So die Gesetzesbegründung, BT-Drucks. 14/6040, 163. 

80 Gesetzesbegründung, BT-Drucks. 14/6040, 163. 

So Gesetzesbegründung, a.a.O., 163. 
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E. Leistungsstörungen im Projekt 



Fallgruppe werden auch Beratungen zu rechnen sein, die aus in Anspruch ge- 
nommenem Vertrauen erfolgen. 82 

535 Die Haftung aus der Aufnahme von Vertragsverhandlungen oder Anbahnung 
eines Vertrages im neuen Schuldrecht (§311 Abs. 2 Nr. 1 - 3 BGB) baut auf der 
gefestigten Rechtsprechung zur c.i.c. auf, 83 weshalb die vorhandenen Grundsätze 
inhaltlich ihre Gültigkeit behalten. Die Haftung entsteht bereits mit dem Anbah- 
nen von Vertragsgesprächen und aus diesem übernehmen die jeweiligen Partner 
(also auch etwa Interessenten auf der Kundenseite) Sorgfalts-, Fürsorge- und Ob- 
huts-, aber auch Aufklärungs- und Beratungs- 84 oder Hinweispflichten, ebenso 
Verkehrssicherungspflichten 85 bezüglich der Rechtsgüter des Anwenders (etwa bei 
Installation oder Reparatur von Systemen bezüglich sonstiger Systeme des Kun- 
den). Vorausgesetzt wird ein Verhalten, das auf einen Vertragsabschluss oder die 
Anbahnung von Geschäftskontakten abzielt, ohne dass es zu einem Vertragsab- 
schluss kommen muss. 86 

536 Allein das Aufnehmen von Vertragsverhandlungen begründet noch keine Ver- 
pflichtung, einen Vertrag auch tatsächlich abschließen zu müssen, ebensowenig 
der Abbruch der Verhandlungen eine korrespondierende Ersatzpflicht, es sei 
denn, eine Seite hat den Eindruck hervorgerufen, es werde sicher zu einem Ab- 
schluss kommen. Eine Haftung dafür, dass es überhaupt zum Vertragsabschluss 
selbst kommt, trifft keine der beiden verhandelnden Seiten, auch nicht für beson- 
dere Aufwendungen im Hinblick auf diesen Vertragsabschluss. 87 Jeder an Ver- 
tragsverhandlungen Beteiligte bleibt also frei, vom Vertragsschluss Abstand zu 
nehmen, ohne dies irgendwie begründen zu müssen. Werden also etwa bei größe- 
ren Projekten Angebote Dritter nur zu Vergleichszwecken eingeholt und mit die- 
sen u.U. auch Verhandlungen geführt, um bei dem in Aussicht genommenen 
Anbieter Preisreduzierungen zu erreichen, oder wird sogar ein Anbieter im Hause 
des präsumtiven Kunden für angebotsbezogene Voranalysen tätig, so begründet 
dieses Vorgehen weder einen Anspruch des Dritten auf Vertragsabschluss noch 
auch nur c.i.c. -Haftung des Kunden. Vielmehr nutzt der Kunde grundsätzlich nur 
bestehende Wettbewerbsverhältnisse, um sich für seine Erwerbsentscheidung 
sachkundig zu machen. Dies ist Anbietern auch grundsätzlich bekannt. Der Kun- 
de ist außerdem in der Verwendung der Ergebnisse, soweit sie in das Angebot 
aufgenommen werden, frei. 



82 Gesetzesbegründung, a.a.O., 163. 

83 Gesetzesbegründung, BT-Drucks. 14/6040, 162. 

84 S. bereits RGZ 95, 58; 120, 251; 162, 156; BGHZ 6, 333; 66, 54. 

85 S.etwa BGHZ 66, 51 (Bananenschale im Verkaufsraum). 

86 Palandt/Heznnc/is § 276 Rdn. 66. 

BGH, NJW 1967, 2199. 
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E.3. Verschulden bei Vertragsschluss (culpa in contrahendo) 
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Ein Abbruch von Vertragsverhandlungen (etwa über ein EDV-Projekt) begründet 537 
nur dann Haftung, wenn der andere Teil in zurechenbarer Weise auf das Zustan- 
dekommen vertrauen durfte und der Abbruch ohne triftigen Grund erfolgt. 88 Dies 
gilt auch dann, wenn der Abbrechende das Vertrauen auf das Zustandekommen 
ohne Verschulden erweckt hat. 89 Erweckt aber der eine Teil durch sein Verhalten 
bei dem anderen Teil das berechtigte Vertrauen, dass es mit Sicherheit zum Ab- 
schluss des Vertrages kommen werde, so geht er damit eine Bindung ein, die zwar 
schwächer ist als der Abschluss des Vertrages selbst, die es aber rechtfertigt, ihn 
wegen eines Verschuldens bei den Vertragsverhandlungen haften zu lassen, wenn 
er vom Vertragsschluss dann doch ohne triftigen Grund Abstand nimmt. Der 
Grund für diese Haftung liegt im schuldhaften Zuwiderhandeln gegen die durch 
das eigene Verhalten hervorgerufene Bindung. 90 Ersatzfähig sind aber wohl nur im 
Hinblick auf dieses Verhalten getätigte besondere Investitionen, nicht jedoch sol- 
che, die gegenüber jedem Interessenten eingesetzt werden (etwa mit Mailing- 
Aktionen). 

Dem Anbieter obliegen bereits mit der Aufnahme von Vertragsverhandlungen 538 
Aufklärungspflichten, insbesondere bezüglich solcher Umstände, die den Ver- 
tragszweck vereiteln können, 91 und die nur dem Anbieter bekannt sind. Dies gilt 
für jede Form möglicher EDV- Verträge, 92 also etwa auch für Auftragsausschrei- 
bungen. (Öffentliche) Ausschreibungen begründen als solche bereits ein vertrags- 
ähnliches Vertrauensverhältnis, das zur gegenseitigen Rücksichtnahme und Loya- 
lität verpflichtet. 93 

Checkliste: Verschulden bei Vertragsschluss 

• Rechtsgeschäftliches oder rechtsgeschäftsähnliches Schuldverhältnisses durch 
tatsächliche Aufnahme von Vertragsverhandlungen, Anbahnung eines Vertra- 
ges oder ähnliche geschäftliche Kontakte (§311 Abs. 2 Nr. 1-3 BGB), 

• Verletzung einer Pflicht nach § 241 Abs. 2 BGB, 

• Vertretenmüssen durch den Pflichtigen (§§ 281 Abs. 1 S. 2, 276 BGB), 

• Schaden, 

• Ersatz des negativen Interesses. 



88 BGHZ 71, 395; BGH NJW 1975, 1774. 

89 BGHZ 71, 395; BGH NJW 1975, 1774. 

90 Zu diesen Grundsätzen siehe OLG Hamm, Urt. v. 5.5.1982 - 19 U 201/81, DV-R 2, 140, 
143 unter Hinweis etwa auf BGH, NJW 1975, 43 und 1774 sowie BGH, WM 1977, 619 

91 BGH, NJW 1985, 1769. 

92 Emmerich, S. 140. 

93 BGHZ 49, 79; Z 60, 223. 




F Vertraglicher Rahmen für typische IT-Projekte 



1. Einführung von ERP (Enterprise Resource Planning)-Software 

Die Einführung von ERP-Software stellt ein geradezu klassisches Beispiel für 
komplexe IT-Projekte dar. 

a) Absicherung überprüfbarer schrittweiser Projektdurchführung 

Die - zu Recht - gefürchtete Kostenexplosion etwa bei ERP-Implementierungs- 539 
Projekten (etwa R/3) durch Beratungsfirmen resultiert zumeist aus nicht rechtzei- 
tig beseitigten Unklarheiten über die Anfangsbedingungen. Anbieter tendieren 
dazu, das Projekt allein aus der Perspektive ihrer Software und Konzepte zu sehen. 

Die Ist-Analyse und ein Soll-Konzept müssen deshalb zur verbindlichen Grundla- 
ge des Implementierungsprojekts gemacht werden, damit das Projekt nicht die 
„Bodenhaftung“ mit der benötigten Anwendung verliert. Weiter ist das Projekt in 
Projektphasen aufzuteilen, in denen jeweils überprüfbare Leistungsergebnisse 
erzielt werden. Im Vordergrund stehen hier weniger Neuerstellungs- als Anpas- 
sungsarbeiten, z.B. Parametrisierung und zusätzliche Programmierung. Mit der 
nächsten Phase darf erst begonnen werden, wenn die vorherige Phase durch den 
Anbieter nachgewiesen erfolgreich abgeschlossen wurde. 

b) Vermeidung der Übernahme historisch gewachsener Abläufe 

Die Integration von einzelentwickelten, historisch gewachsenen, teils undokumen- 540 
tierten Abläufen 1 (oft „EDV-Inseln“ genannt) sollte möglichst vermieden werden, 
da sie zu erheblichem Mehraufwand führen kann, teilweise sogar zu ständigen 
Fehlerquellen an den Schnittstellen zur Standardsoftware (etwa bei unterschiedli- 
chen, jedes Mal erst zu konvertierenden Datenformaten). Soweit diese Integration 
aber unverzichtbar erscheint, müssen der mit ihr verbundene Aufwand (etwa auch 
zur Erstellung erforderlicher Schnittstellen) und die (voraussichtlichen) Auswir- 
kungen auf Antwortzeiten der gesamten Applikation geprüft werden. 






Zum Problem s. Gadatsch, IT-Controlling, in: Tiemeyer (Hrg.), Handbuch IT-Manage- 
ment, 359, 399, 401. 




